>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.
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.
Several of the requirements feel like the quirks of the authors implementation, rather than technological ideals. (Don't reuse previously fetched sith? Fetch each sith lord separately?)
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.
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.
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.
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.
I disagree that this is a good replacement for TodoMVC (not that I'm defending TodoMVC). Two reasons:
1. There is no end-user data input happening in this example, so we can't fully evaluate a potential framework's change tracking/dependency resolution/state update techniques.
2. The "low level" emphasis on controlling AJAX requests isn't a good fit for a lot of frameworks which may be un-opinionated about how data is loaded.
I'm surprised by the negativity from other comments. I agree that this is nice, as an attempt to get people to come up with ideas backed by concrete code to handle what is indeed a difficult problem (i.e. multiple async sources in large non-trivial apps). I don't think it should replace TodoMVC though, as I think they evaluate different things.
I think one missing piece is routing integration... at least this demo has an async and push injections for state, which is better than some systems I've seen... it would be easiest to create a module that has a dispatcher for such event cancellation tracking, likely by a named request queue.
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.
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.
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."
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).
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.
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.
Metrics are subjective, too! What metrics do you choose? How do you value them? How do you interpret them?
Computers especially but science generally lead people to favor the quantifiable to a pathological degree. Software development, like most other complex endeavors, is stubbornly resistant to predictive quantification.
It's also easy to criticize other people's work, but it's a lazy path to being right. There are an infinite number of ways in which something can be considered inadequate or a failure. The number of ways in which a something is good or useful is much smaller. Find the terms on which it's trying to succeed and criticize it there, if you have to criticize something. But introducing your own yardstick and saying "you failed!" is cheap.
He describes elegance as: "the ability of a programmer to easily understand the program's flow and state coordination, being completely familiar with the tools used but completely unfamiliar with the codebase."
You're right that it is not something easily measurable.
The product of code golf is measurable. But, code golf is not usually what you want in production code. Performance is not about characters/lines of code and neither is clarity or maintainability, necessarily.
I don't think there is anything wrong with this sort of requirement. He stated there are no winners. Elegance could really be decided by the community.
Just try to write concise but clear code that would be easily understood by most who are well-experienced in the language/framework.
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.
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.
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.
As of today, it is incredibly hard to evaluate frameworks because you generally only have the time to evaluate small examples, but those are usually easy to do anyways.
This thing here is as tricky as it gets for the scope. Even if the judging is subjective, it is highly revealing.
It sounds like the author is just saying that the definition of elegance is not subjective in this context. The author defines it. Obviously the author's definition contains subjective elements, like who counts as a programmer, who counts as "familiar with the tools used," etc., but I don't think the author is implying that there is a completely objective way to assign a score to each submission.
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.
And if you like CSP, you should consider going all the way to using core.async in ClojureScript. Channels are much more pleasant to use with syntax support.
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.
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.
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.
> 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.
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.