Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate JSON decoder/encoder based on type-definiton #27

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
2 participants
@opvasger
Copy link
Owner

commented Jun 30, 2019

This work addresses #19 by generating the required (and annoying) boilerplate to make full use of these devtools:

  1. JSON encoder/decoder for messages. decode (encode msg) == msg should always be true - otherwise fail in a clear and informative way.
  2. JSON encoder for the model. If values are opaque, simply write them out as a string.
  3. JSON decoder for the model. It is unclear to me exactly how this should work, but probably something along the lines of unlocking a write-mode for the model, where you can:
    1. Pause the app and replace a value in the model.
    2. Replay any previous state with that replacement.
    3. Continue the app from that previous state without the replacement.

This approach will initially be based on static-analysis of code, but could probably be done (better?) with stoeffel/elmi-to-json, which statically analyses the build-cache.

@opvasger opvasger self-assigned this Jun 30, 2019

@MartinSStewart

This comment has been minimized.

Copy link

commented Jun 30, 2019

Two questions:

  1. Will the debugger offer any guidance when it comes to modifying the model? For example, if the model looks like this
type Model 
    = Loading
    | Loaded LoadedState

type alias LoadedState = 
    { 
    -- Lots of fields
    }

and the user wants to switch from Loading to Loaded via the debugger, will they need to carefully enter in all the json fields needed to correctly decode Loaded? Unless the debugger has knowledge of the models structure (which I don't think it will if it's only given an encoder and decoder) then it seems like the best the debugger can do is tell the user it couldn't parse their changes and show the generated json error.

  1. If the user modifies the model via the debugger, does this make it impossible for the debugger to save and replay the history past that point?
@opvasger

This comment has been minimized.

Copy link
Owner Author

commented Jun 30, 2019

  1. I want fields to be editable, but I dunno yet. Experiments will tell if there is a way.
  2. Editing model fields won't affect the history at all. It's a temporary thing where you can check out what that state would look like ☀️
@MartinSStewart

This comment has been minimized.

Copy link

commented Jun 30, 2019

  1. Only setting existing fields is a good first step. If you're going the code generation route then I imagine something like this should be possible as well https://package.elm-lang.org/packages/avh4/elm-debug-controls/latest/
  2. That makes sense, thanks!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.