To me Immutable.js reduces a lot of headaches and it's a great library, but now im facing with a trouble, my original object comes from the server but when I use any of it's functions like fromJS({myObj}) it works but saves a copy but sorted "a-z" and I'm making something that need the original structure to keep the components in the order that comes from the server, someone any Idea?
fromJS translates your objects into lists and maps by default. The former is ordered but not keyed, while the latter is keyed but not ordered, so neither fits your use case.
What you're looking for is an OrderedMap, which is a Map with an additional insertion order guarantee:
import { OrderedMap } from 'immutable';
const orderedMap = OrderedMap({key: "value"});
You can achieve it by still using fromJS: It has a second parameter called reviver, which can be used also for using OrderedMaps instead standard Maps:
import Immutable from 'immutable';
const reviver = (key, value) =>
Immutable.Iterable.isKeyed(value) ? value.toOrderedMap() : value.toList();
const data = Immutable.fromJS(js, reviver);
Javascript core objects explicitly provide no guarantees about key order. Immutable.Map (the expected result of your fromJS() call) just follows that.
If you want order, you should either specify the order as another property on each item, or, more conventionally, create an Immutable.List from an Array.
In other words, this sounds like a square peg/round hole problem. Make sure you're using the right data structure for your task.
Related
In ReactQuery, the useQuery(..) hook takes a key that can contain complex dependencies (in an array). Or even just an int, like todoId that can change (cf the documentation).
Or a filters object like below:
function Component() {
const [filters, setFilters] = React.useState()
const { data } = useQuery(['todos', filters], () => fetchTodos(filters))
// ✅ set local state and let it "drive" the query
return <Filters onApply={setFilters} />
}
I'm unable to find an explanation regarding how it does monitor changes under the hood.
If the hashing of the key is well explained in the source code and this blog post the event-handling/monitoring of the value changing is a mystery to me.
So the question is: how does it keep track of changes, even inside complex typed passed in the Query Key array? Is there some introspection happening connecting events to value and/or reference changes?
PS: It is a question also applicable to dependencies in the useEffect(..) hook. There is a general perplexity from me, coming from non-interpreted languages.
Ok, since my comment was stolen as an answer even without a mention, I just repost it as an answer myself:
Query restarts when key hash changes.
how does the system know to recompute and compare the Hashkey? How does it "respond" to a change?
It recomputes hash on every render basically, no magic here.
Hash algoritm is an implementation detail, but by default it uses JSON.stringify (the only detail is that the object keys are sorted).
In the opposite, useEffect hook compares deps just by reference (if you can say so, technically it probably uses tc39.es/ecma262/#sec-isstrictlyequal e.g. ===).
The query keys are hashed deterministically. Basically, we JSON.stringify the key, but sort the keys of objects inside it so that they are stable. After that, we have just strings (you can also see them in the devtools), and strings are easy to compare to see if something changed (just ===).
how does the system know to recompute and compare the Hashkey?
we just do this on every render.
I have a design annoyance with some existing code in JS. The code is working, so I have no desperate hurry to change it, but the duplication shown below does annoy me. What is the usual/recommended/official way of avoiding this situation?
The actual system is a large/complex financial system, so I have simplified it to the most basic example which demonstrates the problem:
var colours={
red:{id:"red", vals:[1,0,0]},
green:{id:"green", vals:[0,1,0]},
grey:{id:"grey", vals:[0.5,0.5,0.5]}
// ...etc
};
// id needs to be known internally within the object - thus it is defined as a property.
// e.g:
colour.prototype.identify(console.log(this.id));
// id also needs to be used externally to find an object quickly.
// e.g:
function getcolour(s){return colours[s];}
// Although this works. It does mean duplicating data, with the theoretical possibility of a mismatch:
var colours={//...
blue:{id:"green", // oh dear...
How would this normally be handled by the experts?
This question is somewhat subjective.
When creating my applications I typically try do do the following:
never define same data in multiple places. source should always be unambiguous
if I need to create any indices for faster/easier access, I use utility methods to do it. Those methods should be properly unit-tested, so that I would have little doubts on them doing the wrong thing
use third party libraries as much as possible (such as already suggested lodash or underscore) to minimize the amount of code to be written/maintained.
If your algorithms and utilities are properly unit-tested you should not worry (too much) about getting the data into inconsistent state. However, if those are critically important systems/interfaces, you may add some validation on output. And it is generally a good practice to have data validation and marshaling on input.
Explanation on the utility methods:
if you have data array, say
var data = [{"id":"i_1", ...}, {"id":"i_2", ...},{"id":"i_3",....}];
Then and you have to create an index out of that or create more data sets based on the original array, then you create yourself a library of utility methods that do the modification on the array, create derivative data sets, or iterate on the array and create a resulting item on the fly. For example:
var createIndex = function( arr ){
// do something that converts the data array with expected structure to object
// {
// i_1: {"id":"i_1", ...},
// i_2: {"id":"i_2", ...},
// i_3: {"id":"i_3", ...}
return newObj;
}
This method will create a hash-map to access your data, which is faster then to iterate over the original array all the time. But now, this method you can easily unit-test and be sure that when you use it on the source data to get your intended dataset, there will be no inconsistency.
I wouldn't change the colours[key] direct access with other method to avoid duplication.
Any other attempt will lead to processing and you have mentioned that you have a large amount of data.
I assume that the duplication is over the incoming data that is a waste.
An example of processing over the network data consuming could be, going over the map object and set the id dynamically according to the key. (processing vs traffic)
colours[key].id = key
You can filter your object converting it to an array of objects and then filtering unique values. Converting it to an array would allow you to perform a lot of operations quicker and easier.
So you can map your object to an array:
var coloursArray = myObj.map(function(value, index) {
return [value];
});
Remove duplicates:
function removeDuplicates() {
return coloursArray.filter((obj, pos, arr) => {
return arr.map(mapObj => mapObj[id]).indexOf(obj[id]) === pos;
});
}
You can remove duplicates from an array using for example underscore.js through the .uniq method:
var uniqueColoursArray = _.uniq(coloursArray , function(c){ return c.id; });
Moreover, this function is pretty useless because you can access your element directly:
function getcolour(s){return colours[s];}
Calling colours[s] it is also shorter than getcolour(s). Your function would make sense if you pass also the array because it is not accessible in some other scope.
Then I can't understand why you do pass a console.log as parameter here:
colour.prototype.identify(console.log(this.id));
maybe you would like to pass just the this.id
I’m making a collection of React Elements and displaying them; what follows is a trivial example to frame the problem of how-would-one-modify-an-preexisting-instantiated-element only.
var c = [
<div>A</div>,
<div>B</div>,
// ...
<div>Z</div>
];
var ListComponents = React.createClass({
render: function() {
return <div>{c}</div>;
}
});
ReactDOM.render(<ListComponents/>, document.getElementById('root'));
While the code above “works,” it renders a console message I’d rather not ignore:
Warning: Each child in an array or iterator should have a unique "key" prop.
Check the render method of `ListComponents`.
See https://fb.me/react-warning-keys for more information.
Superficially, I could just add a unique key="…" string to each element in c and be done with it.
However, that seems a quite verbose, especially since I have the data in an indexed array and a functional language that in theory can assign each key its matching index value without manually having to enter it as a source literal.
I’d love to be able to just do this...
c.forEach( (e,i) => e.key = i ); // ...or call some setter
What’s the *right* React-way to do this -and- keep the code clean?
ADDENDUM:
...for the curious or those that want to just say add a key field...
The collection I'm using is actually an array of tuples containing meta-data and a corresponding React Element, a custom Component, or some huge JSX block. The example above overly trivializes what the actual data looks like as well as its irregularities.
As the source data itself is quite long, updated often, and not maintained by a developer; it is highly error prone to missed key fields or duplicates values from manual entry. Hence the desire to do it entirely programmatically. I can not count on the data owners to do it properly. They can't read code, so ideally I'd rather not mess up the data structures with a lot of "programming goop."
The collection is manipulated a few times, putting various runs of certain elements into other dynamically created wrappers, so that the final collection is actually generated by a few transformations, filters, and maps before it is ultimately displayed.
A major shout out to Wes Bos, who came up with a clever solution that works!
The code is a simple one liner and does exactly what I was looking for:
c = c.map( (el,key) => React.cloneElement(el, {key} ));
We're building a new collection using the .cloneElement() method, which I was unaware of. That was what I needed, it turns out.
In the .map() operation, the lambda function is passed both the element and the index. It's return value is a cloned element, but with the key property set.
By cleverly naming the index element key, it allows the short notation for the expression { "key" : key }. This object augments the cloned object.
In the end, I end up with a new collection of identical objects, each with a key property set to the index.
I am a little confused by the functionality of ImmutableJS when working with an array of objects. The following example shows that even though the List x is immutable, I can still modify properties of objects inside the list both with and without using Immutable List's update() function.
My question is, why would I use Immutable if I can still modify the contents of my objects? I expected this module to protect me from that. I realize that I will not be able to add or remove entire objects to/from the list, but that doesn't fully protect me from modifying the list, which when working with a list in React state, I do not want to be able to do.
The other interesting thing I noticed is that when I directly modify the name after first performing the update, x.get(0).name and y.get(0).name are both changed. I thought that the resulting list from update() would not contain references to the same objects in the list.
How and why is ImmutableJS really helping me in this case?
var x = Immutable.List.of({name: 'foo'});
console.log(x.get(0).name);
var y = x.update(0, (element) => {
element.name = 'bar';
return element;
});
console.log(x.get(0).name);
console.log(y.get(0).name);
x.get(0).name = 'baz';
console.log(x.get(0).name);
console.log(y.get(0).name);
Output:
foo
bar
bar
baz
baz
https://jsfiddle.net/shotolab/rwh116uw/1/
Example of #SpiderPig's suggestion of using Map:
var x = Immutable.List.of(new Immutable.Map({name: 'foo'}));
console.log(x.get(0).get('name'));
var y = x.update(0, (element) => {
return element.set('name', 'bar');
});
console.log(x.get(0).get('name'));
console.log(y.get(0).get('name'));
Output:
foo
foo
bar
While the last example shows what I was trying to accomplish, ultimately I don't know if I will end up using Map or List or even ImmutableJS at all. What I don't like is the alternate APIs (especially for a mapped object). I am afraid that when I hand my project off to another developer, or as others join the team, using these immutable objects and lists correctly will completely fall apart without the proper governance.
Maybe this is more of a commentary on React, but if React intends for the state to be immutable, but it's not enforced, it just seems to me like this will end up a mess in a project that is moving quickly with multiple developers. I was trying my best not to mutate the state, but forgetting that modifying an object in a list/array is very easy mistake to make.
The immutable.js does not provide true immutability in the sense that you could not modify the Objects directly - it just provides API which helps you to maintain the immutable state.
The update -function should return completely new version of the indexed object:
var y = x.update(0, (element) => {
return { name : "bar"};
});
But doing something like this is a big no-no: x.get(0).name = 'baz';
Here is a much better explanation of the whole thing than I could ever write:
https://github.com/facebook/immutable-js/issues/481
The point of immutable.js is to allow re-use of objects which are not modified, which consumes less memory and gives a good practical performance.
There is also library "Seamless immutable", which freezes the objects, so that they can not be modified, but this comes with some performance penalty under JavaScript: https://github.com/rtfeldman/seamless-immutable
In my react/redux app, I am setting states in my reducers using something like this :
state.set('search', myResults);
the state is an immutablejs Map(). The format of the object when toJS() is run on it (no longer an immutable object) is like so :
{
results: { ..all results in here }
}
So you'd have state.search.results.
and this works great, however I have a scenario where I need to "push" into the search part of this map. I was thinking merge would take care of this however it does not seem to work as I assumed it would. I have tried :
state.mergeIn('search', singleResult);
as well as
state.merge({ 'search': singleResult });
neither seem to be working. The intended result is to have that single result pushed into the state Map() (and not overriding it like with .set). So the desired result would end up looking like this :
{
results: { singleResult pushed or merged into here with other results }
}
I am unsure how to do this with immutablejs, any advice would be greatly appreciated. Thanks!
You need to use update for this. Merging does not concat arrays together in the key.
state.update('search', search => search.concat(singleResult));
Also be aware that if search contains a normal JS array - then the array itself is still an mutable data structure. Immutable.JS doesn't do deep conversion of datatypes unless you use fromJS().