Lisplog

Blogging in Lisp

Search

Feed Aggregator

Rendered on Fri, 22 Nov 2019 12:02:25 GMT  newer latest older 
Next udpate: Fri, 22 Nov 2019 12:30:00 GMT feeds

Links in package.elm-lang.org to the source code of every function

via Elm - Latest posts by @David-Gil David Gil on Fri, 22 Nov 2019 10:50:06 GMT

Thank you so much for all this info!! It’s just what I needed to begin with it.

At least, I think I’ll learn a lot from trying. I’ll see what I can do.

Thank you again,

David Gil

Elm-spa: a tool for building single page apps

via Elm - Latest posts by @ganlhi Guilhem Brouat on Fri, 22 Nov 2019 08:37:42 GMT

I wanted to check the examples again, and I saw the new complex example. I saw dynamic params, and transitions, that seems very interesting! I cannot run it though, because I don’t have the right version of elm-spa… Will the CLI be able to generate pages with dynamic params?

Elm spa example header with shared button (on Click) attribute

via Elm - Latest posts by @dmy on Fri, 22 Nov 2019 08:13:24 GMT

The viewHeader function in my example does not have to be literally in the Main.elm module.
It can be in its own module, taking a msg argument:

Main.elm

import Header

type Msg
    = HeaderClicked
    | GotHomeMsg Home.Msg


view model =
            ...
            in
            { title = title
            , body = Header.view HeaderClicked :: List.map (Html.map toMsg) body
            }

Header.elm

view : msg -> Html msg
view onClick = 
    div []
    [ button
        [ onClick msg ]
        []
    ]

or if really needed could have its own Msg which would be mapped like the pages ones.

At the, end, all messages are Main ones, for example:

type Msg
    = HeaderMsg Header.Msg
    | GotHomeMsg Home.Msg
    ...


view model =
            ...
            in
            { title = title
            , body = Html.map HeaderMsg viewHeader :: List.map (Html.map toMsg) body
            }

I would strongly prefer the first solution (the msg argument(s)) as long as one or two messages for the header are enough.

Elm spa example header with shared button (on Click) attribute

via Elm - Latest posts by @pdamoc Peter Damoc on Fri, 22 Nov 2019 08:01:49 GMT

This is a good attitude. You usually have only one Main.elm and it pays to take extra care not to make it a magnet for things that would have ended up in other modules with more careful consideration.

Elm spa example header with shared button (on Click) attribute

via Elm - Latest posts by @Nikolis_Galerakis Nikolis Galerakis on Fri, 22 Nov 2019 07:32:00 GMT

Thank you I will consider this approach carefully.

Elm spa example header with shared button (on Click) attribute

via Elm - Latest posts by @Nikolis_Galerakis Nikolis Galerakis on Fri, 22 Nov 2019 07:29:56 GMT

Looks like the obvious answer, I was just avoiding to put to much on the Main because of fear it becomes to big and more complex than I can manage. And because of a comment by RFeldman saying
“-- NOTE: Based on discussions around how asset management features
– like code splitting and lazy loading have been shaping up, it’s possible
– that most of this file may become unnecessary in a future release of Elm.
– Avoid putting things in this module unless there is no alternative!”
but I guess there is not apparent alternative on this one.

Elm spa example header with shared button (on Click) attribute

via Elm - Latest posts by @pdamoc Peter Damoc on Fri, 22 Nov 2019 04:23:45 GMT

The way I model this is to have global state and global messages. This global state is updated in the Main and sent down to the view and the update of pages as a form of context.

A very similar pattern is elm-shared-state (formerly elm-taco).

How to refactor this conditional piping

via Elm - Latest posts by @system system on Thu, 21 Nov 2019 21:18:46 GMT

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.

Links in package.elm-lang.org to the source code of every function

via Elm - Latest posts by @dmy on Thu, 21 Nov 2019 20:19:21 GMT

As described in this old pull request, the info would not really be added to the site, but to the package documentation, which is then used by the package web site to render the package specific page.

Here are a few pointers:

If you want to explore this feature, you could try to add line numbers to the compiled package documentation in the compiler, patch the documentation decoding library to get them, then to test more easily, you could use for example a custom version of elm-doc-preview (which includes a forked version of the package.elm-lang.org frontend) to add links to source code per function/declaration (on GitHub). Finally, once this works, you could port the patch to package.elm-lang.org frontend.

So at the end, you would need at least 3 patches:

Good luck, you will most likely be on your own, as there is not much documentation except for the project-metadata-utils package. There is also no guaranty that it would be merged.

Elm spa example header with shared button (on Click) attribute

via Elm - Latest posts by @dmy on Thu, 21 Nov 2019 19:37:59 GMT

One way could be to render the header in the Main outside the page specific view (without using Html.map).

I think it is quite common for SPAs to render the layout of the app (header or app bar, footer, menu) this way in Main with Main messages, and then render the page only inside its container with Html.map.

Something like:

type Msg
    = HeaderClicked
    | ChangedUrl Url
    | ClickedLink Browser.UrlRequest
    | GotHomeMsg Home.Msg
    ...

view : Model -> Document Msg
view model =
    let
        viewer =
            Session.viewer (toSession model)

        viewPage page toMsg config =
            let
                { title, body } =
                    Page.view viewer page config
            in
            { title = title
            , body = viewHeader :: List.map (Html.map toMsg) body
            }
    in
    ...


viewHeader : Html Msg
viewHeader =
    div []
        [ button
            [ onClick HeaderClicked ]
            [ text "Click me" ]
        ]

and you would remove the banner view from each page.

Problem with naming modules in 0.19.1

via Elm - Latest posts by @stephenreddek Stephen Reddekopp on Thu, 21 Nov 2019 19:08:50 GMT

You can build multiple Main files into a single js file by passing them into elm make together. For example, you could run elm make src/Init.Main.elm src/Main.elm. This will produce one file with one instance of the elm runtime and with both of your entry points. When you import the file in javascript, perhaps as Elm, then you reference them like: Elm.Init.Main.init(...) and Elm.Main.init(...).

Problem with naming modules in 0.19.1

via Elm - Latest posts by @wolfadex Wolfgang Schuster on Thu, 21 Nov 2019 17:42:27 GMT

They are compiled to 2 separate JS files. I’m fairly certain you can have multiple entry points in the same file, in my case though they are separate because they are being loaded by separate HTML files.

Using bug fixes in a public dependency

via Elm - Latest posts by @system system on Thu, 21 Nov 2019 17:09:48 GMT

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.

Problem with naming modules in 0.19.1

via Elm - Latest posts by @bdrp Lars on Thu, 21 Nov 2019 14:40:06 GMT

Are they compiled to separate js files or the same? Can you have two entry points in the same file.

Understanding extensible records

via Elm - Latest posts by @dmy on Thu, 21 Nov 2019 12:18:44 GMT

Yeah, Elm works usually better with flat models (without nested extensible records or nested fields).

Bogus data should be avoided. A simple way would be to use a Maybe Bool for the model selection status and for isSelected. It might be preferable though to use a custom type like:

type selection
    = Unselectable
    | Unselected
    | Selected

Understanding extensible records

via Elm - Latest posts by @GabeAtWork Gabriel Théron on Thu, 21 Nov 2019 12:14:24 GMT

That is pretty nice and works well to avoid redefining the fields, thank you! The only downside that remains is the relation between Foo and Fooable. It won’t necessarily be intuitive for a newcomer to understand the difference between the two.

I suppose extensible records are not really made for this use case. For now on my real-life project, I’ve kept a record with isSelected defined in, without extensible records, as it’s much simpler. Only downside is, I have to sometimes provide bogus isSelected data just so I can pass it to some functions.

I’ll keep on coding and I might find a better way to solve the underlying problem :construction_worker_man:

Elm spa example header with server generated content

via Elm - Latest posts by @Nikolis_Galerakis Nikolis Galerakis on Thu, 21 Nov 2019 12:03:27 GMT

Hello Folks,

So I am developing an application using the elm-spa-example by rfeldman.
I lately found my self in a situation where I would like to include server generated content on the header.

Kind of how Facebook notifies you whether new messages for you came in.
The problem I think is apparent in the elm-spa-example the main method is the aggregator and every Page has it’s own message type and main has a Custom Msg type with variants for every possible page msg type in the application.

Then in the module that creates the view (Page.view) it passes the view of the particular page that is supposed to be on the screen which is of type Html PageMsgType and the Main method is mapping it to it’s local message type which has a variant for every posible PageMsgType containing the PageMsgType so it can then parse the message when a component is clicked or something and forward it to the appropriate update function of the particular page.

My problem now is that I would like to implement the functionality described above and what I actually was thinking of is create a button with events that are handled in the Main module but somehow it’s not possible (at least as far as I can understand) because what I am actually trying to do is compose a an Documet with more than one Msg types, PageMsgType and MainMsgType .

Have you ever encountered a situation like the described before ? How would you go with this ?

Didier Verna: Quickref 3.0 "The Alchemist" is released

via Planet Lisp by on Thu, 21 Nov 2019 00:00:00 GMT

Following up with the latest release of Declt, I'm also happy to announce the release of Quickref 3.0 "The Alchemist", our reference manuals aggregator for Quicklisp libraries. The official website has been updated yesterday with both the latest Quicklisp version, and the new Declt, resulting in the documentation of 1792 Common Lisp libraries.

 newer latest older