From the Meteor documentation:
Session provides a global object on the client that you can use to store an arbitrary set of key-value pairs. Use it to store things like the currently selected item in a list.
Question:
"Arbitrary" might be a little too vague for developers. How is the is the Meteor session implemented on the client and what are its limitations (if any) ?
The implementation of Session is very light weight. It's basically a key-value store that can also store and invalidate reactive contexts. It is also a good starting point for learning how to extend meteor with your own reactive functions.
You can read the whole implementation here:
https://github.com/meteor/meteor/blob/master/packages/session/session.js
Related
I would like to store a function / component inside the Redux state to pass it to another part of the application.
I've read that this is not recommended, but what exactly will happen?
Will it affect the performance of other data stored on Redux to the point it becomes visibly slow to the user?
Will it cause components that depend on this component or any data stored on Redux to continuously re-render causing the app to slow to a crawl?
Will Redux just break randomly all the time?
What are the actual, practical downsides to doing this, putting aside the intentions behind the creation of the library?
Do not put functions or components (non-serializable value) in redux state or actions
Avoid putting non-serializable this can break the following things:
debugging
server side rendering
state persistence
and more, this can create performance issue
This is described more in depth here in the official documentation
I've decided to just store the component I needed on Redux and haven't seen any downsides, which led me to believe there is no real issue in doing this, as long as you don't care about serialization.
I would like to save a function (reference) to my Redux store so that I can:
pass the function references to components that are connected to the store state, or
retreive a stored function and run it within an action creator.
The general consensus seems to be that you should not store function references in the Redux store (because the data should be serializable). Are there any ways to get around this so that the above two processes can be realised?
Per the Redux FAQ entry on non-serializable items in state:
It is highly recommended that you only put plain serializable objects, arrays, and primitives into your store. It's technically possible to insert non-serializable items into the store, but doing so can break the ability to persist and rehydrate the contents of a store, as well as interfere with time-travel debugging.
If you are okay with things like persistence and time-travel debugging potentially not working as intended, then you are totally welcome to put non-serializable items into your Redux store. Ultimately, it's your application, and how you implement it is up to you. As with many other things about Redux, just be sure you understand what tradeoffs are involved.
I create JavaFX project that includes a few controllers and different windows. I want to transfer data from one object to another controller. At the time when I get another window wants to data previously entered remain in their fields. Is the will use the database and continuous upload and download data from it is a good solution? Perhaps the creation of JSON and the object of it in each controller is the better option? Can someone say something about this? Or propose a better solution?
You have some options:
Using a database as a middle man: It's a very bad idea in my opinion. Databases should hold the data that must be persisted and
their persistence actually represents a concept from problem domain.
Some temporary data that can be held in RAM are not good fits for
that (even if they are going to be significant and good fits in the
near future). In addition, it introduces problems like performance
decrease and a constant need to check data integrity everywhere (i.e.
you always have to be sure every time the data in RAM changes, the
database gets updated too.)
Singleton pattern for storing state: you can have a singleton class that holds all your temporary data. This approach is a lot like
database approach as you have some data source (as a middle man) that
can be accessed from multiple points in your program, but instead of
a database it's stored on RAM. So you are going to have similar
problems but it's more efficient than a database and by holding
references to singleton data objects, you can handle data integrity
problem much easier (because when you alter your data object
references you know that it's the original object that actually gets
altered and you don't have to be worried about that.)
BUT it's a very bad idea either! Using singleton pattern for storing state is an antipattern. It's not how this pattern
intended to be used. Read more here: Why is Singleton considered an anti-pattern?
Using dependency injection frameworks like Spring: you can hold your data in spring AppicationContext with (singleton scope) and
inject it wherever you want. Again this approach is essentially
similar to previous approaches but it's a little bit cleaner because
you're not using a static singleton class and so it may enhance
testability of your application.
Using third-party JavaFx frameworks: There are some JavaFx frameworks that can handle problem of data sharing among many
controllers. You can see some examples by reading my answer to a similar question here. Here is an example from DataFx samples which
represents data sharing among two separate sender and receiver views
with distinct controllers:
by pressing send, the sender sends the data and receiver receives it. You can see the details in the jar or in my answer.
Further reading:
Passing Parameters JavaFX FXML
I'm learning redux and am struggling to understand why state has to be immutable. Could you provide me with an example, in code preferably, where breaking the immutable contract results in an not so obvious side effect.
Redux was originally invented to demonstrate the idea of "time-travel debugging" - being able to step back and forth through the history of dispatched actions, and see what the UI looks like at each step. Another aspect is being able to live-edit the code, reload it, and see what the output looks like given the new reducer logic.
In order to be able to properly step back and forth between states, we need to make sure that reducer functions have no side effects. That means data updates need to be applied immutably. If a reducer function actually directly modifies its data, then stepping back and forth between states will cause the application to behave in an unexpected fashion, and the debugging effort will be wasted.
Also, the React-Redux library relies on shallow equality checks to see if the incoming data for a component has changed. If the data references are the same, then the wrapper components generated by connect assume that the data has not changed, and that the component does not need to re-render. Immutable data updates means that new object references are created, and thus connect will see that the data has changed and the UI needs to update.
Two Ideas
There are two ideas about immutability that you need to understand:
Mutate the state only in the reducers
Using an immutable data structure
Mutate the state only in the reducers
Redux tries to ensure that you only mutate the state in the Reducers. This is important because it makes easier to think about your application data flow.
Let's say that a value is not displayed in the UI as you expected or that a value that should have changed still showing its original value.
In that case, you could just think about which reducer is causing the mutation and see what went wrong.
This makes thinking about Redux issues very simple and makes developers highly productive.
Sometimes you can mutate the state in a view or in an action by mistake. If you think about the life-cycle:
Action -> Reducer -> Views-> Action
If the state changes in a view and then an action is triggered the state change could be override. This would make very hard to find out what is going on for developers. We solve this by mutating state only in the reducers.
Note: another nice thing is that reducers are pure functions and all the async stuff takes places in the actions/middleware. So all side effects take place in the actions/middleware layer. Actions are our connection with the external world (HTTP, Local Storage, etc.).
Using an immutable data structure
As I have already mentioned, sometimes you can mutate the state in a view or in an action by mistake. To reduce chances of this happening we can make state mutations explicit by using and immutable data structure.
Using immutable data structures also has performance benefits because we don't need to perform deep equality checks to check for mutations.
The most commonly used provider of immutable data structures is immutable.js.
I think the key ideas would be
Easy to replay any given situation/test flow - you can replay with the same actions starting from the same initial state
Fast component re-rendering - because the reference is changed and not its values, it is much much faster to test the change
Of course, there are other aspects and I suggest this nice article which explains in more details.
I come from a background in embedded systems where you're really careful about memory management. With Redux especially its concept of immutability.
So let's say I'm modifying a member of an array. I have to create a new array that links to all original members plus the modified item.
I understand why using Immutability improves the speed but my question is since we essentially never remove the old copies of the objects and create new ones, Redux still keeps a reference to the old objects because of time traveling features.
Most machines these days have quite a lot of memory, but shouldn't at least in theory the Redux app crash because the tab/process runs out of memory? After a long use maybe?
No. First, Redux itself doesn't keep around old data - that's something that the Redux DevTools addon does. Second, I believe the DevTools addon has limits on how many actions it will track. Third, Javascript is a garbage-collected language, so items that are no longer referenced will be cleaned up. (Hand-waving a bit there, but that generally covers things.)
Immutable.js leverages the idea of Structural Sharing while creating new copies of collections. It implements persistent data structures and internally uses concepts like tries to implement structural sharing. So, if you created a list with 10 items, adding a new item to it will not create a new list.
Persistent data structures provide the benefits of immutability while
maintaining high performance reads and writes and present a familiar
API.
Immutable.js data structures are highly efficient on modern JavaScript VMs by
using structural sharing via hash maps tries and vector tries as
popularized by Clojure and Scala, minimizing the need to copy or cache
data.
I suggest you watch this awesome talk by Lee Bryon, Immutable.js creator