elm-lang.org | Server and client code for the Elm website | Web Framework library

You've flipped the arguments to List.foldl. The fold function takes the value first and the accumulator second, while your recurse function takes the accumulator first and the value second.

The simple fix to this is to eta expand the recurse function and flip the arguments when passing it to foldTree:

Rather than comparing entire chunks of Html msg together, you'll get better results using the Test.Html.Query module (and corresponding Test.Html.Selector and Test.Html.Event modules). This allows you to create more targeted tests (e.g. testing whether a certain element has certain text or a certain class, rather than testing the entirety of the HTML structure). And the test failures do provide much more context to help you debug.

I've built an example on Ellie, here's the basics of what a test might look like:

Generating random values is an effect and as such a pure language cannot just perform it.

However, there is a pure version of randomness, which is using random seeds. These have the property that every time you generate a value using the same seed, you get the same value - hence this is just a pure computation and is completely ok in a pure context.

Elm allows you to execute effects as Cmd, the thing you return from your init and update functions. So one option you have is to always return Random.generate GotANewUUID UUID.generator before you need it, then perform your computation when you handle the GotANewUUID msg.

The other option is to keep track of the random seed. You either start with a deterministic one with Random.initialSeed (probably not what you want with UUIDs, as they would be exactly the same on every run of your program), or in your init function you return Random.generate GotNewSeed Random.independentSeed. Then you store the seed in your model. Every time you need to generate a new UUID, you use your newUuid function above, making sure to store the new seed.

Here's an example:

Rather than using the fixed offset that Time.here provides, an alternative is to pass in the result of Intl.DateTimeFormat().resolvedOptions().timeZone (MDN) through the flags at startup.

Using justinmimbs/timezone-data, parsing it on the Elm side may look something like:

Let's consider an example:

• name: Apple, price: $3.2, pic: 🍏
• name: Banana, price: $2, pic: 🍌
• name: Orange, price: $2.8, pic: 🍊

Now let's imagine that the user sorts by price:

• name: Banana, price: $2, pic: 🍌
• name: Orange, price: $2.8, pic: 🍊
• name: Apple, price: $3.2, pic: 🍏

without keyed nodes, the diffing is going to look like this:

• name: AppleBanana, price: $3.22, pic: 🍏🍌
• name: BananaOrange, price: $22.8, pic: 🍌🍊
• name: OrangeApple, price: $2.83.2, pic: 🍊🍏

which is going to issue in this example 9 replaceElement operations with 9 createTextElement operations (for example, the exact semantics might work slighly differently, but I think the point stands).

The keyed version will understand that the order changed and will issue a single removeChild and appendChild for the apple node.

Hence all the performance savings are on the DOM side. Now this is not just for performance, if those lists had input elements, keeping them keyed if you had your cursor in the Apple input, it would stay in the apple input, but if they weren't keyed, it would now be in the banana input.

You are correct that without lazy the diffing still happens, but the diffing is generally the cheap part, the more expensive part is actually patching the DOM, which is what keyed helps prevent.

You can use elm-svg-string instead of the official SVG library and produce the string version of the SVG. You can then take the string version, encode it with Url.percentEncode and use it as the href for a download link and as src for an image in order to display it for preview purposes

This is surprisingly involved and part of it is I suspect that a proper transition library specifically designed around elm-ui is (AFAICT) still missing.

The basics steps are like this:

1. Define properties for the start and mouseOver states.
2. Figure out which properties these correspond to in elm-simple-animation.
3. Add a transition for those.

I haven't used Elm in a while but was curious about this myself.

At first glance, the key mechanism solves a problem outlined here: https://github.com/elm/browser/blob/1.0.2/notes/navigation-in-elements.md —or at least has something to do with that contention.

The immediate takeaway is that they wanted to prohibit you from accessing the URL-changing API unless you created your app with Browser.application, so one way to do that would be to require a dummy type like Key as input that you can only get if you use Browser.application. But there's more to the key than that.

Browser.application, unlike Browser.document and Browser.element, gives you additional handlers: onUrlRequest and onUrlChange.

So, how is it communicated to your application when the URL changes? How is it implemented?

The source code here explains a lot: https://github.com/elm/browser/blob/53e3caa265fd9da3ec9880d47bb95eed6fe24ee6/src/Elm/Kernel/Browser.js#L142

In particular, this is what's held in the Key opaque type:

The form library doesn't explicitly support what you're trying to do, but we can make it work!

Here's my example of how you can take JSON and create a form: https://ellie-app.com/bJqNh29qnsva1

Form.list is definitely the promising path. You're also exactly right that Form.list requires all of the fields to be of the same type. So let's start there! We can make one data structure that can hold them by making a custom type. In my example, I called it DynamicFormFieldValue. We'll make a variant for each kind of field. I created ones for text, integer, and select list. Each one will need to hold the value of the field and all of the extras (like title and default value) to make it show up nicely. This will be what we decode the JSON into, what the form value is, and what the form output will be. The resulting types looks like this: