19 comments

[ 2.6 ms ] story [ 52.8 ms ] thread
This is awesome. Thanks a lot for these cartoons. Please keep going, you have found a great niche!
This is probably the best introduction to Flux I have read. I think people (in general) respond better to visual representations of complex processes- and this visual story nails it.
For me, it's not the pictures that convey the message so much as the words. By telling a story with actors who have goals, run into obstacles and find ways to surmount them, the author is using language in a way that it evolved for. I recall reading a study that showed people generally solve logic puzzles better if they are framed as stories within a social context, rather than as abstract questions.

The pictures help illustrate the text, but while the text could (almost) stand alone, the pictures could not.

There is a following guide to Redux and its differences to Flux at the end of the article[0]. Great explanation!

[0] https://code-cartoons.com/a-cartoon-intro-to-redux-3afb77550...

Indeed great explanation, but the Flux one seemed a little easier for me. This is the first time I read about redux, and even with the cartoon it feels complicated.
I love that the cartoon he used in that one included Richard Ayoade's "The IT Crowd" character. I read that cartoon's interactions in his voice in my head. Really livened up the presentation. :-)
*she
Mea culpa. I would edit my comment but it's apparently too late. My apologies to the author.
Bonus reference: the root component is Denholm Reynholm. One of the lines in the cartoon is cribbed almost directly from episode 1.
This is a real good introduction, but I wouldn't call it a cartoon.

It's a big text with many drawings.

Everytime I read the title I think "wow super easy panels and stuff" but then I see the wall of text.

Great work.

However: while I feel this cartoon (and other Flux introductions I've seen) capture well the concepts behind Flux, none of them make up for the amount of boilerplate and just over-the-top abstractness (IMO) that goes into actually implementing vanilla Flux.

To me that is the biggest problem to make it easier for people to adopt it, not understanding the concept.

This. Once I got my head around flux, it made sense, and I understood why its a good way of designing the data flow inside a web application, but as someone who likes to hack together projects quickly, setting up a flux architecture required a lot of effort on my side, effort I would rather spend building out functionality.
My advice: drop Flux, and use Redux instead. There is less boilerplate, and it improves on Flux's original ideas.

http://redux.js.org/

Great! I would love to see more of these :-)
As a C++ dev, I am suprised that Facebook got credit for a rather standard model view paradigm.
Neat cartoon. It helped me understand Flux a little bit better.

In step #4 (Once it’s done changing state, the store lets its subscribed view controllers know), why can't the child views just subscribe directly to the stores and remove the view controller as a middle man?

I really like the way the author anthropomorphizes the pieces of the flux architecture here. I am in the middle of writing a saltstack tutorial and wonder if I should do the same.