This module provides a simplified way to separate the initialization process of an application, where random values have not yet been generated, HTTP responses have not yet arrived, and so on.
By using this module, you can define two model types:
one that exists only during the initialization phase,
and another that exists only during the running phase.
This helps you avoid flooding your model with Maybe values
that are needed only to represent the absence of data during initialization.
elm make --debug and
need more detailed information during the initializing phase,
check out the Initialization.Debuggable module.Initialization.Advanced module for more control.Similar to Browser.element, but with more flexibility during the initialization process.
In the first argument record, you define the initialization phase with its own model type,
initializingModel.
The Cmd (initializingModel -> initializingModel) value returned from the function assigned
to the init field describes how initializingModel values should be transformed
by effectful commands.
(Use Cmd.batch to execute multiple commands. Note that their execution order is not guaranteed.)
toRunning is called every time initializingModel is updated.
If it returns Ok ( runningModel, runningMsgCmd ),
the initialization phase ends immediately,
and the running phase defined by the second argument record begins,
as if ( runningModel, runningMsgCmd ) were returned from the init function
of a normal Browser.element.
With blockingReason values,
you can represent why the initialization phase is still in progress
and the running phase has not yet started.
For simple use cases, the blockingReason type can just be String,
but you may also use a custom type to represent richer, structured reasons.
These values are returned by toRunning when it fails to convert
initializingModel into ( runningModel, Cmd runningMsg ),
and are passed to initView so that you can display the current state
to users of your web application.
⚠️ If toRunning returns Ok _, the initialization phase ends immediately,
and any remaining Cmd (initializingModel -> initializingModel) values are ignored.
Be careful not to return Ok _ while waiting for indispensable command results,
such as those from an HTTP request.
Initialization.Debuggable.element instead.Initialization.Advanced.element, which allows:Cmd values during the initialization phaseSimilar to Browser.document, but with more flexibility during the initialization process.
In the first argument record, you define the initialization phase with its own model type,
initializingModel.
The Cmd (initializingModel -> initializingModel) value returned from the function assigned
to the init field describes how initializingModel values should be transformed
by effectful commands.
(Use Cmd.batch to execute multiple commands. Note that their execution order is not guaranteed.)
toRunning is called every time initializingModel is updated.
If it returns Ok ( runningModel, runningMsgCmd ),
the initialization phase ends immediately,
and the running phase defined by the second argument record begins,
as if ( runningModel, runningMsgCmd ) were returned from the init function
of a normal Browser.document.
With blockingReason values,
you can represent why the initialization phase is still in progress
and the running phase has not yet started.
For simple use cases, the blockingReason type can just be String,
but you may also use a custom type to represent richer, structured reasons.
These values are returned by toRunning when it fails to convert
initializingModel into ( runningModel, Cmd runningMsg ),
and are passed to initView so that you can display the current state
to users of your web application.
⚠️ If toRunning returns Ok _, the initialization phase ends immediately,
and any remaining Cmd (initializingModel -> initializingModel) values are ignored.
Be careful not to return Ok _ while waiting for indispensable command results,
such as those from an HTTP request.
Initialization.Debuggable.document instead.Initialization.Advanced.document, which allows:Cmd values during the initialization phaseAn applicative-style helper that accumulates blocking reasons.
toRunning : { mTimezone : Maybe Time.Zone, mPosixTime : Maybe Time.Posix } -> Result (List String) ( { timezone : Time.Zone, posixTime : Time.Posix }, Cmd msg )
toRunning { mTimezone, mPosixTime } =
Ok (\timezone posixTime -> { timezone = timezone, posixTime = posixTime })
|> accumulate (Result.fromMaybe "No timezone" mTimezone)
|> accumulate (Result.fromMaybe "No posix time" mPosixTime)
A type alias for
Platform.Program flag <internally defined model type> <internally defined msg type>.This type is intended to be used in the type annotation of the
mainfunction.