last time I told you about a handy Flux feature: you can handle the asyncronous code as sync one. So before we begin, I’ll describe the issue:
- there is a big table, let it be 10k x 10k cells;
- it’s possible to show only 10 x 10 cells on screen at once.
- User can navigate in any direction of that big data canvas;
- we can ask the server for a brief version of data (request takes <500ms);
the full metadata package for 10 x 10 cells area is downloaded in 1.5-2s.
So once the user finished the navigation, we need to show at least something quickly then be ready to show all the metadata. Behind the UX we have to do two requests and handle the data respectively. How this could be done in Flux?
let me share some opinions about the Flux application architecture. Before we begin, let’s take a look at the two-way data binding features. It sounds interesting and promises you easy development. It even does so.
Until your app is big enough.
Once you need to look under the hood of how it works, it’s really hard to understand the data flow, all the points where data could be changed and the sequence of these changes. There is simpler way of data management using one-direction data flow.
after a lot of boring and abstract stuff let’s do something really interesting. Let’s make things move!
before we start making things move, one more boring thing that helps us in development.
The issue is, we don’t know when exactly game events happen. But we need to respond somehow on these events. For instance, we never know when the user moves the mouse but we need to move the racket accordingly.
The event handling mechanism comes to rescue.