Ever since I first talked to Bruce about this(and other Om/React users), I've thought that this type of approach could lend itself really well to visual image based regression testing.
The other cool thing is that with Om you can serialize record Om state transactions. By doing this you could see how people are using specific components. Perhaps you could cycle through the last 10 users or the 10 most common interaction patterns of a component and view those interactions on a card.
This could be a boon to interaction designers looking to see how people are using disparate components/pages within an application.
Actually, that's not pie in the sky, running selenium against a set of cards would work great. And may be an easier env to work in than the actual main app.
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.")
I 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.
I have only seen Chris's Strange Loop presentation. So I don't know much about his plans for Aurora. I do agree that the time is ripe for a visual programming language built in the browser.
I haven't looked into LT integration just yet. But I am open to that of course. Sounds like an absolutely great idea.
Devcards is still super new. And I hoping that people really think about what this means in their particular workflows and hopefully reintegrate knowledge back into Devcards.
Sure, will do. I was actually looking at that just before I posted.
My initial thought (before seeing your FAQ) was a no-op compile, but you rightly point out that this may not be the best approach due to littering the production code. I will probably go the separate devcards files route and have the production profile exclude these.
Maybe src/ test/ and devcards/ ?
But I'll experiment with it and see what works best for me and let you know.
You're talking about the leinigen template? I just don't like the current situation for distributing these resources. I figure if you want, you can always download and store these resources locally if you want.
The other cool thing is that with Om you can serialize record Om state transactions. By doing this you could see how people are using specific components. Perhaps you could cycle through the last 10 users or the 10 most common interaction patterns of a component and view those interactions on a card.
This could be a boon to interaction designers looking to see how people are using disparate components/pages within an application.