>Scroll buttons: up/down buttons, move the list 2 positions<p>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.<p>"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 <i>very</i> 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."<p>And then, upon closer inspection... I realize that most of the requirements are pretty convoluted.
Cool, starred this for later! I want to see the results and compare with our current flux architectures at my work place.<p>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.
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.<p>This should reveal potential pain points a lot better.
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.
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?<p>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."
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.
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.
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.
A solution in vanilla javascript:<p><a href="https://github.com/stinson7/flux-challenge/blob/master/submissions/stinson7/index.html" rel="nofollow">https://github.com/stinson7/flux-challenge/blob/master/submi...</a>
looking at this (only vague understanding of Flex), I don't quite see why Flux would have difficulties with this.<p>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.<p>Feel like I'm missing something
> being completely familiar with the tools used but completely unfamiliar with the codebase<p>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.<p>I do not find Flux elegant at all, personally.