Flux Challenge
github.com
github.com
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.
- ajax async requests
- an event that causes events to stop
- an event that causes the ui interactibility to stop
- an event that causes more loading to be needed, triggering multiple simultaneous ajax async requests
- a web socket communicating constant information which would cause current requests to get interrupted potentially
The point is: many moving parts, each part affects the others.
However, seriously Obi-Wan needs a better methodology.
GraphQL and relay are designed to solve his issue with async requests and state, not flux.
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 should reveal potential pain points a lot better.
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.
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?
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 really like this and hope that there are many entries.
"I'm curious about every solution's pros and cons, and I would prefer to discuss over evidence/artifacts instead of with platitude arguments."
best way to move a conversation forward I've seen in too long.
Presumably Stalz intends to use cycle and show that capturing everything as an Observable is a good unifying framework.
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."
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.
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.
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.
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.
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.
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.
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.
https://github.com/stinson7/flux-challenge/blob/master/submi...
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
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.
That's ALL of it. What do you find to be inelegant: fold, or a pure map function?