Devcards – Taking Interactivity to the Next Level | Hacker News Reader

Devcards – Taking Interactivity to the Next Level

rigsomelight.com

105 pointsbrucehauman22 comments

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.

To expound on this, what about having cards, ie single components, be linked to a graphical/interaction test CI-suite.

I know this is sort of pie in the sky but it gets me thinking.

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 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.

I'd love to hear what your experience is and/or see examples.

Mind. Blown. Time for me to get serious about learning ClojureScript ^_^ Thanks for putting this together; it's amazing!

Really glad you liked it.

This is great work. The video in particular sold the idea to me.

Projects like this are really making me want to build something substantial in ClojureScript.

Yeah, the coincidence with Apple's release of swift and playground is eerie! But this is opensource and for Clojure! Oh man, that's exciting!

Bruce, how does this compare with Chris Granger's plans for Aurora? And, have you considered making this a Light Table plugin?

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.

Cool, thanks for making this, I'm going to try to check it out soon.

BTW, I assume you've seen Bret Victor's talks, but if not, you absolutely must, especially Inventing on Principle.

This is really cool. Going to look at integrating this into my Clojurescript/Om development workflow.

Let me know how it goes. I'm still trying to figure this out

https://github.com/bhauman/devcards#what-do-i-do-for-deploym...

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.

Looks nice. Any particular reason why this isn't packaged so that it works offline? (Ie: bundle up css/js resources)?

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.

This is awesome, Bruce. Looks like you were up before Apple!

So, what are your plans?

I love this visual approach for testing and debugging frontend interactions.

opensource = awesome alternative to Playground.

Reply on news.ycombinator.com