# Transitioning from element to application

**URL:** <https://discourse.elm-lang.org/t/transitioning-from-element-to-application/9015>\
**Category:** Learn\
**Created:** [March 18, 2023, 4:09pm UTC](https://discourse.elm-lang.org/t/transitioning-from-element-to-application/9015 "2023-03-18T16:09:00Z")\
**Posts on this page:** 1\
**Showing post:** 11

<div class="post-metadata">

**Author:** ![AlanQ](https://avatars.discourse-cdn.com/v4/letter/a/e9bcb4/32.png) [@AlanQ](https://discourse.elm-lang.org/u/AlanQ)\
**Post date:** [March 27, 2023, 2:05pm UTC](https://discourse.elm-lang.org/t/transitioning-from-element-to-application/9015/11 "2023-03-27T14:05:45Z")

</div>

Many thanks for all the interesting replies and explanations, gratefully received.  
It looks like elm-spa is the way to go… 🙂  
[Edit] …I’ve just discovered [Elm Land](https://elm.land/): Ryan’s upgrade of elm-spa…

* * *

> [@paulh](#):
>
> might be something the OP would be interested in too.

I’m very interested in this whole branch of the topic 🙂  
`Model = Custom Type` vs `Model = Record`.

In a previous question I asked, [Is it inefficient to pass the whole model from function to function?](https://discourse.elm-lang.org/t/is-it-inefficient-to-pass-the-whole-model-from-function-to-function/8379)

I think a relevant point from this discussion is that a complex structure like the model is _passed by reference_. So, whether the model is data for each page plus session data inside a record, or a custom type of one page at a time plus session data, there’s no efficiency gain or loss.

> [@paulh](#):
>
> This [model as record] approach is useful if you want to maintain the state of each page…

Which I think I am typically very likely to need.

* * *

> [@Carsten\_Konig](#):
>
> it’s not about the type alias - it’s about having to construct the full tuple [record] (with all models for each page) for/on every requested page/url - so you need some “invalid” or “empty” page-models for all the other pages.

Could we somehow use each page’s `init` to populate the ‘empty’ values?  
Alternatively, might the record entry for each page be a `Maybe`?

I’m still finding my way around _elm-spa_, but it seems to solve this one by combining Carsten’s and Paul’s approaches — a `custom type` _inside_ a `record` — plus auto-generation:  
The underlying model is a record in _.elm-spa/defaults/Main.elm_

```auto
module Main exposing (main) 
import Gen.Pages as Pages 
type alias Model =
    { url : Url
    , key : Key
    , shared : Shared.Model
    , page : Pages.Model
    }

```

`Pages.Model` = `Model.Model`:

```auto
type Model
    = Redirecting_
    | Home_ Gen.Params.Home_.Params ()
    | NotFound Gen.Params.NotFound.Params

```

So each time a page is added (`elm-spa add`), a new option is added to the `Model.Model`.

* * *

_Minor note on the Document body type_

> [@Carsten\_Konig](#):
>
> 1. Don’t know but having a `List` is much nicer - at least I always have more than one element inside `body` so this keeps you from having a dummy-`div [] [...]` to wrap this up.

> [@kanishka](#):
>
> I would expect this to be a list. If body is the html body tag, then I see the value of body as the children of the body tag, which I would expect to be a list.

Even when writing raw html, I always use a ‘dummy’ `div` because it feels wrong to style the top-level `body`. And, in the case of the `Document` type, there is no mechanism to style the `body`:

- if it has three unstyled child `div`s, they sit one above the other
- style them as `float: left` and they sit side by side
- but if we want flexbox styling, we can’t style `body` as a `flex` parent. So, for example, everyone using `elm-ui` ends up with something like `body = [myElmUiBody]`.

It’s like a painting studio that favours the painters of triptychs over those who just use a single canvas: every frame comes with a hinge, whether you need it or not 😉

---

_[View the full topic](https://discourse.elm-lang.org/t/transitioning-from-element-to-application/9015)._