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 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.