Flux: Should Stores inform components about what's changed?

Question

I have a question regarding web application architecture such as Flux and related. Note that I don't use React.js, this question is purely about the architecture.

If I understand the concepts in Flux correctly, a Store informs components about changes. Components are then supposed to fetch all the data from the Store. What happens when I want to know exatly what have changed in the data? When ReactJS is used, the whole data could be given to React which then uses well designed diff and virtual DOM algorithms to apply the changes. But what if there's no React and there's a large amount of data?

Real life example

New data comes through WebSockets every 1-2 seconds. The data is added to the Store, but one of the components needs to know exatly what is changed (imagine that new data needs to appear in the view with some kind of animation). There's a lot of data, iterating over the whole array and comparing every element is not an option. Furthermore, intuitively it doesn't feel right because parts of the application know exactly whas it changed so why the view can't?

I was looking for the solution and I found three suggested approaches:

1. The Store informs exactly what is changed (against the Flux rules)
2. The Store keeps last changes and provides a public method getLastChanges()
3. Additional Store which keeps only the last changed data.

Architecturally speaking, what's the proper solution here?

Answer 1

But what if there's no React and there's a large amount of data?

In this case, Flux architecture doesn't apply well. Why do you want to use it?

Flux works well when views (or whatever's subscribed to the stores) can efficiently perform operations based on the knowledge of the current (and, sometimes, the previous) state alone . If this is not the case in your domain area, don't use Flux.