3 ms·
This approach has a lot of appeal- I am building lots of Om components that change over time, and things that change over time are hard to debug. With this app
by drcode 12y ago
This approach has a lot of appeal- I am building lots of Om components that change over time, and things that change over time are hard to debug.
With this approach, I could put in different devcards for snapshots in time for my components, and debug those in a static manner, and see them all in front of me at the same time.
The one additional feature I'd like to see (or maybe it exists already, I just looked at the project briefly so far) is to have a single Om appstate that mutates over time, going from card to card. Then, if I want to document/debug an action by the user requiring multiple steps, I could see each intermediary in the chain of actions. (i.e. "If the user clicks here, they see this. If they now type this here, they see this.")
- brucehauman 12y agoI have been working towards that. If you are still following the queue of messages that you mentioned a while back, then you could supply each card instance of your "program" with the list of messages that you need to get to the state you need. So you could make a loop to create the list of cards you want to look at.
- drcode 12y agoI think I might make devcards part of my regular workflow. It seems obvious now, seeing devcards, that the ease with which Om/React can render "snapshots" makes this the most sensible way to develop for Om.
- brucehauman 12y agoI'd love to hear what your experience is and/or see examples.