Renamed to FabienHenon/app-object. It is published under that name, and new versions come out there.
Versions published as calions-app/app-object still install under that name. 1 version of 1 come from the new location (see their notes).
Rerouted (renamed, verified). The GitHub user or repository was renamed. The tag is still there, at the new name. The Lamdera package server serves a copy recovered from https://github.com/FabienHenon/app-object.
What we checked: The repo moved to github.com/FabienHenon/app-object. Rebuilt with git archive from commit c638222af4ec of https://github.com/FabienHenon/app-object (zip prefix calions-app-app-object-c638222/, America/Los_Angeles times): the zip is byte-identical to the one package.elm-lang.org recorded, SHA-1 7a2562ba9f263025cfb37d6bc411346d5d6c2c5a.
The Lamdera compiler uses this copy and prints a one-line notice saying so. elm itself fails to download this version.
Details · package.elm-lang.org's zip: https://github.com/calions-app/app-object/zipball/1.0.0/
The AppObject is an object that encapsulates the Model and Cmd Msg of a component (returned in side effect functions like init or update) plus and appData object and a Cmd appMsg.
These new elements are a model and commands related to the entire application.
Let's say for instance that you have a component that does something (whatever) and that needs to open a modal, or set the connected user, or set the user language of the application, ... All of these states/effects are related to the application, not to the component. Indeed, the component itself can't open a modal because it's the application's responsibility. Also, the component could save the connected user to its own state, but it's a data the entire application would like to know about and with the classic architecture of elm apps it's not possible for a component to tell the app that it should update its state.
To make it simpler: a component can't change the state of its parent component and can't send commands with its parent's messages.
This is what AppObject is for, it allows you to:
Creates a new AppObject from the appData and your component's model
Adds a new component's command to this AppObject
Adds a new global command to this AppObject
Maps your AppObject to change the types of appData, appMsg, model and msg
Maps only your appData
Maps only your appMsg
Maps only your model
Maps only your msg
Merges 2 AppObjects together. You provide the functions used to:
modelappDatamsgappMsgReducer that allows you to update or create an AppObject for each element of a list
Allows you to create a new AppObject from an existing one, using the appData and the model. The new Cmd appMsg and Cmd msg will be batched to the
existing ones
Executes your AppObject. That means that you will create a ( model, Cmd msg ) tuple from an AppObject, this allows you to run your side effects and model updates
in your root update and init functions
AppObjectis the object you should return from your side effect functions (init,update) in your components.appDatarefers to the model you want to be global to your application. This model is usualy stored in your root stateappMsgrefers to themsgtype you want to be global to your application. Thismsgis usually handle in your rootupdatefunctionmodelrefers to the model of your current componentmsgrefers to themsgtype of your current componentI suggest your create a module that defines your
appDatamodel and yourappMsgmessage type, and you define atype aliasof your ownAppObjectwith theappDataandappMsgset :