
Flux Challenge - staltz
https://github.com/staltz/flux-challenge
======
pierrec
>Scroll buttons: up/down buttons, move the list 2 positions

The first thing I would do in this situation is that I would sit down with
Obi-Wan (or his hologram) and try to smooth out any problematic requirements.

"Master Kenobi, I understand that you've required a custom scrolling system,
and agree that it fits very well in the unified look you're going for.
However, experience tells me that this is a move we might later regret and
have to backtrack on. Custom scrolling systems are currently _very_ poorly
supported by browsers, and I strongly suggest that we use native scrolling.
The scrollbar can be styled, but our styling will not appear in all browsers."

And then, upon closer inspection... I realize that most of the requirements
are pretty convoluted.

~~~
andy_ppp
Yes this is very much a straw man...

GraphQL and relay are designed to solve his issue with async requests and
state, not flux.

~~~
chadaustin
Actually, I think this problem is great. Flux sounds great on paper but these
edge cases keep coming up again and again. How do you handle optimistic
updates? Request serialization? Garbage collection in your stores? (Or do you
just let them grow forever?) Flux doesn't solve these problems. Relay, on the
other hand, does a much better job of tackling the actual hard problems of
application structure head on.

------
jxm262
Cool, starred this for later! I want to see the results and compare with our
current flux architectures at my work place.

It would be cool to see more things like this, maybe here on HN, or maybe some
other website? I really like TodoMvc but it's a bit too simplistic to see the
strengths/weaknesses of each library/framework. Sometimes you need something
more in-depth to start getting the larger picture of what patterns and
architecture works well. Also.. sometimes I feel like I'm floundering trying
to make something elegant, then to find out later someone else already has
thought through alot of the nuances. If I had some easy way to search for what
the community deems as "good" code, it could really help speed up development.

------
Retozi
This is great! In my opinion, this should not only be a challenge for Flux
frameworks, but generally replace todoMVC as the "go-to" example
implementation.

This should reveal potential pain points a lot better.

~~~
sgrove
The main problem I see is that TodoMVC is immediately clear as an app and its
requirements - this has a bunch of Star Wars-related stuff that distract from
what the challenges and requirements of the app (both for a hypothetical user
and for the implementors).

I like the idea of a fuller common-comparison app (and even some of the
requirements of this app), but not sure this is the right framing.

~~~
jsprogrammer
Even without the Star Wars stuff, it's not really clear what value this app
provides.

To me it appears to just be a cursable priority queue component. Such a
component should be provided by a standard library, not implemented as its own
app. Of course, this is a learning exercise so some leeway is afforded, but it
might be even more effective to include extracting the core component into a
reusable library as part of the challenge.

Also, what is a Todo app, but a priority queue?

------
z3t4
I like challenges like this because I can prove you can write elegant
solutions using only vanilla JavaScript, HTML and CSS. This one is too
restricting though, why not push all request via the websocket? That's how I
do things nowadays, using sockJS to provide compatibility with old browsers
that don't support Websockets.

~~~
tel
Because it's written intentionally to make data access patterns which are
weird. Having multiple modalities should theoretically make a lot of different
design options awkward.

Presumably Stalz intends to use cycle and show that capturing everything as an
Observable is a good unifying framework.

~~~
tel
Staltz _

------
firasd
Given that Flux was made to go hand-in-hand with React I think all those XHR
requests are somewhat non-idiomatic. Wouldn't it be better to just have a
WebSocket sending across a large list of the latest data, sending a new list
any time there's an update?

edit: Maybe I am misunderstanding and the way data is received in this
challenge is meant to demonstrate your point about "multiple async data
sources."

~~~
jkarneges
Yeah, I think the point was to showcase many async operations, and to perhaps
have simpler code. Certainly in a real-life scenario it would be better to
optimize by transferring the items as lists (though XHR would be just fine for
that too, at least for initial population).

~~~
firasd
Yeah. So in my experience “state” based UI really pushes your app towards
“real-​time”, almost like a multiplayer game. Given that your entire UI is
rendered from a certain set of data, you definitely don’t want to be in a
position where you are personally reconciling the data structure in the
browser with data received from the server.

In my view it’s best for when you can directly tell the server, “here’s my
latest data”, or ask the server: “What’s up? What’s the latest?” Think Gmail,
or Facebook comments. So it’s okay if the two states (server vs. client) get
out of ‘sync’, to support something like Offline Editing, but the data
received should be in an expected structure.

Oddly, a simple and clear way to think about this is that it's similar to
server-side templates. You instantiate your variables first, then just run the
rendering function. If the rendered view has to change it's still based on
conditions or booleans held in your variables; you change them and run the
rendering function again. That's how server-generated HTML works.

------
kevincox
I would like to see some transitions, as that is something that I have found
hard to do in a bunch of frameworks.

------
javajosh
This just about the most blatant nerd sniping that I've seen. "The Flux
architecture sucks; try to prove me wrong."

------
kyberias
Give me a break with your "elegance". No matter how you twist it, it's
subjective unless you provide some actual metrics. Once you do that, you might
notice it's not "elegance" any more, it's something else.

~~~
cnp
I think that after a certain point in time in ones coding life it becomes
fairly easy to determine the elegance of a small codebase. This is a
reasonable ask.

~~~
nostrademons
Yes, except that that determination will be specific to the person doing the
determination. That's the definition of "subjective".

Try submitting the same code to the IOCCC [1], the ICFP programming contest
[2], the computer language benchmarks game [3], and the Flux Challenge (well,
assuming they had the same problem statement, and that you could emscripten
your C code for the Flux Challenge). They all have prizes for elegance. The
only one of their definitions of elegance that is objective is the benchmarks
game, which defines it as straight lines of code (and has resulted in some
entries that most programmers consider to be abominations "winning"). It's
different cultures, different judges, and different criteria for what's
elegant.

[1] [http://www.ioccc.org/](http://www.ioccc.org/)

[2] [http://icfpcontest.org/](http://icfpcontest.org/)

[3]
[http://benchmarksgame.alioth.debian.org/](http://benchmarksgame.alioth.debian.org/)

~~~
cnp
Sorry, but I think the authors ask is clear, simple and unambiguous. Your
comment above strikes me as unnecessarily pedantic when paired with the
challenge.

------
kaonashi
Sounds like the solution you're begging at is to use something like bacon.js
or csp inside of the flux actions.

~~~
jlongster
Now you're making me want to implement this with the js-csp library to show it
off.

But you're exactly right. Redux (imho the best "flux" implementation out
there, quotes because its only partly flux) is not against async abstractions
like channels or observables. It just eschews requiring them as the backbone
for communication with the UI, and favors a simple naive state change
notification. But in action creators, if you need to do complex work, you
should absolutely use channels or observables to synchronize stuff, and then
dispatch simple actions to make state changes.

I've found it really, really nice to constrain async abstractions into a
single place. It makes the rest of the code just normal synchronous stuff
(i.e. all the UI code, about 70% of our app), and you can do record/reply
simply by just replaying actions.

------
teen
I've read this about 10 times and don't understand the problem at all. Seems
like an extremely easy thing to do in angular. You just fire requests and
cancel ones not in the view? I think the problem could be better explained in
the readme.

------
debacle
Is this challenge too trivial to really show the strengths of Flux? I feel
like it would be easy to bang out an implementation in jQuery in about 30
minutes.

~~~
GhotiFish
I think this challenge is crafted to attack some oddities in flux that makes
doing this difficult.

Another team working across the hallway from me was using flux style react for
a cordova application, and they hit some hideous cases that resulted in
bizarre looking code.

I've being hearing a lot of cursing from over there, and this is relative to
the team that manages spring/hibernate/queryDSL/angularJS oddities.

------
stinson7
A solution in vanilla javascript:

[https://github.com/stinson7/flux-
challenge/blob/master/submi...](https://github.com/stinson7/flux-
challenge/blob/master/submissions/stinson7/index.html)

------
rtpg
looking at this (only vague understanding of Flex), I don't quite see why Flux
would have difficulties with this.

Isn't most of the "hardness" solved by writing a good store? Your controller
view makes a bunch of UI requests, and the store decides whether or not to
notify based off of the ordering of the requests.

Feel like I'm missing something

------
aikah
> being completely familiar with the tools used but completely unfamiliar with
> the codebase

here lies the problem.Someone familiar with a specific pattern may find it
more elegant that someone who is not familiar with the said
pattern/paradigm/framework. I'm found of OOP, show me a codebase with
mountains of FP everywhere and I might not find it elegant. Elegance here is
really in the eye of the beholder.

I do not find Flux elegant at all, personally.

~~~
z5h
React builds a pure function that maps data to UI. Flux is a fold over a
stream of events that generates a stream of data states.

That's ALL of it. What do you find to be inelegant: fold, or a pure map
function?

~~~
headinthebox
I presume you mean `scan` not `fold`.

------
PaulHoule
Why should I do this when there lots of paying and non-paying work of various
sorts out there already?

~~~
TheCoelacanth
Why would you browse HN when there is lots of paying and non-paying work of
various sorts out there already?

