I’ve spent a significant amount of time designing and implementing elm-devtools, which is very close to release. The value-proposition of that project includes what I’m presenting here, but as the core ideas behind those developer-tools are very simply, I wanted to publish that core first!
Great work, I’ll try it out! But I have some doubts. 1) Does it take a long time to encode/decode an app with lots of msgs? 2) Every module that has it’s own Msg type need now to export an encoder/decoder? 3) And what about Elm Codec package, would it be easier to write encoders and decoders?
I have done a performance-test here for devtools, which employs the same strategy as this module! Performance in this module should be even better due to a couple of things:
All messages are pre-encoded (as soon as they update), which makes writes to cache much faster! devtools doesn’t do this for a number of reasons that isn’t relevant to this module.
This module uses something I’ve called a DenseList to ensure every message is only stored once, and then maps those to an array of integers. This makes the cache-write much smaller. I’ve also ensured encoding (on update) and decoding (on init) only does one pass across the values when recalculating the application-state.
It’s really fast IMO. The performance-stuff will only ever be relevant for applications that use RequestAnimationFrame - if this subscription is not running in your application I feel safe guaranteeing no performance problems.
This problem is addressed here. In a sentence, I’ll be building a CLI that can generate the code for you - I plan to do this after the release of devtools.
I haven’t looked into this! Thanks for sharing - I’m making note of this, and will look more into it once I get around to building code-generation for JSON-en/decoders.
Let me know if I something was unclear, or if you have more questions!