This module provides whole control over the initialization process.
For most applications, the simpler Initialization.element API is sufficient.
Use this module only if you need finer control over the initialization phase,
such as dynamic command creation.
What you do with this module is basically to define two independent TEA application, one representing initializing process and the other running process, and to define one conversion function from initializing model to running model.
Similar to Browser.element, but with more flexibility during the initialization process.
In the first argument record, you define the initialization phase in the same way as a normal TEA element.
Here, toRunning is called every time initializingModel is updated.
When it returns Ok ( runningModel, runningMsgCmd ), the initialization phase is terminated,
and the running phase defined by the second argument record begins,
as if ( runningModel, runningMsgCmd ) were returned from the init function
in an ordinary Browser.element argument record.
By introducing the blockingReason type,
you can represent the reason why the initialization phase is still in progress
and the running phase has not yet started.
This value is returned by toRunning when it fails to convert initializingModel
to ( runningModel, Cmd runningMsg ),
and is used by initView to display the current state to users of your web application.
⚠️ If toRunning returns Ok _, the initialization phase is forced to end,
and any remaining Cmd initializingMsg values are ignored.
Be careful not to return Ok _ while waiting for command results that are indispensable for your app,
such as an HTTP request.
Similar to Browser.document, but with more flexibility during the initialization process.
In the first argument record, you define the initialization phase in the same way as a normal TEA document.
Here, toRunning is called every time initializingModel is updated.
When it returns Ok ( runningModel, runningMsgCmd ), the initialization phase is terminated,
and the running phase defined by the second argument record begins,
as if ( runningModel, runningMsgCmd ) were returned from the init function
in an ordinary Browser.document argument record.
By introducing the blockingReason type,
you can represent the reason why the initialization phase is still in progress
and the running phase has not yet started.
This value is returned by toRunning when it fails to convert initializingModel
to ( runningModel, Cmd runningMsg ),
and is used by initView to display the current state to users of your web application.
⚠️ If toRunning returns Ok _, the initialization phase is forced to end,
and any remaining Cmd initializingMsg values are ignored.
Be careful not to return Ok _ while waiting for command results that are indispensable for your app,
such as an HTTP request.
An applicative-style helper that accumulates blocking reasons. Blocking reasons are accumulated in reverse order of application.
type alias InitializingModel =
{ mTimezone : Maybe Time.Zone
, mPosixTime : Maybe Time.Posix
}
type alias Model =
{ timezone : Time.Zone
, posixTime : Time.Posix
}
toRunning : InitializingModel -> Result (List String) ( Model, Cmd msg )
toRunning { mTimezone, mPosixTime } =
Ok (\timezone posixTime -> ( { timezone = timezone, posixTime = posixTime }, Cmd.none ))
|> accumulate (Result.fromMaybe "No timezone" mTimezone)
|> accumulate (Result.fromMaybe "No posix time" mPosixTime)
toRunning (InitializingModel Nothing Nothing)
--> Err ["No posix time", "No timezone"]
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.