Compiler trips up on extensible records?

[jako]

Thank you, @francescortiz. I have unmarked @Philipp_Krueger’s answer as the solution, but I would still like to recognise him as the person who helped me understand the core of the problem. I hope this bug gets fixed soon.

[jako]

At the moment I am trying to refactor my code, to see if a solution involving nested records is feasible. If I run into difficulties, I will give the Ellie a shot instead.

[dmy]

@francescortiz Have you reported a bug by the past? It seems that this issue has not been clearly reported, likely because not much people design their types around extensible records due to their limitations.

As an aside, if you have found a suitable and useful use case for extensible records, it would be interesting to share it.

@jako Yeah, if you get stuck, and share a minimal example with the Ellie, maybe we can help finding another solution.

[jako]

Have you written anything about atomic design in Elm, or do you have any good links to share? What Elm patterns are you using to make it work?

[Philipp_Krueger]

I don’t know why I didn’t think of mentioning it earlier:
In case anyone wants to isolate code that triggers elm compiler bugs, take a look at my project, elm-reduce.
You provide it with a shell-file that tests whether the compiler output contains the bug and tries to remove code irrelevant to the bug in a step-by-step fashion.

I have let it bit-rot a little, because I’m missing newer compiler bug examples and use-cases recently (0.19.1 has been great :D). Please contact me if you want to use elm-reduce. I’d love to pick it up again and update it correctly to 0.19.1.

[francescortiz]

I haven written about it. But the post is about to expire, so I am going to to make a short explanation. With atomic design (https://bradfrost.com/blog/post/atomic-web-design/)::

• We have simple atoms that don’t require full Elm understanding. Good for a growing team.
• Molecules and organisms can be stateful or stateles.
• We use the OutMsg pattern for child to parent communication. I don’t think wi will ever need parent to child communication, since this is just about rendering. We have made a library based on elm-reply, but with support for more than one reply and I think simpler and more explicit api.
• Templates are also kind of simple, since they just put pieces together and proxy the data to each of the components of the template.

Then, since all that was just rendering, regarding application structure, we have for layers:

• Application: Takes care of the usual: session (or context), routing, etc.
• APIs: Make the queries and provide functions to process the data. The goal is that when we do repaints as much as possible has been calculated in the update function (we do a lot of calculations per API call).
• Page: It is a controller. It handles all the side effects and feeds the Template.
• Template: Explained before.

Benefits:

• It is very easy to split the tasks.
• For each task, the required knowledge base is scoped.
• Re-usability.

I think this is a good enough quick overview.