-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
@computed.shallow decorator #2437
Comments
|
But it still not decorator?.. |
@Amareis see https://deploy-preview-2327--mobx-docs.netlify.app/refguide/computed.html, the section about In your case for example, by introducing a shallow comparison, you would make adding or removing items to the collection that don't match the filter cheaper (since then an updated collection would still result in the same output), but all other cases (like toggling So it is fine to use those mechanisms, but beware that they can make things actually significantly slower instead of faster, so they shouldn't be applied without though, and the current api reflects that. (I think |
For arrays shallow comparing is actually good enough, since I understand your point, but, still, currently to avoid unessesary recomputes (for decorators) there is only |
@Amareis are you aware you can already specify a shallow comparer with the decorator syntax? @computed({ equals: comparer.shallow }) I thought I'd add my two cents on to this one as I frequently use shallow comparison. Just to be clear, I am completely happy using the I often define objects which contain multiple properties ready for use in a UI component. For example: interface IBook {
title: string;
isRead: boolean;
} The values come from different observable data collections and these data collections store data for many books. I make a shallow computed function which maps the data to an IBook object: @computed({ equals: comparer.shallow })
get book(): IBook {
return {
title: this.bookData.get(this.selectedId).title,
isRead: this.readStauses.get(this.selectedId)
};
} If I used a regular computed function it would mean that any change to an underlying data collection would trigger a view update. Whereas using shallow comparison only triggers a view update if the particular book I'm interested in has changed. |
@jezzgoodwin constructor() {
this.selectedBook = observable({
get title() {
this.bookData.get(this.selectedId).title;
},
get isRead() {
this.readStauses.get(this.selectedId)
},
});
}
get book(): IBook {
return this.selectedBook;
} |
@urugator your code is a better approach for the basic example I gave. I will keep this idea in mind. Generally when I construct an object with multiple properties it's because I need to do some conditional logic and I don't want to have to repeat it. Eg, I wouldn't want to repeat my conditional logic within both the title and isRead getters. Also when I make these types of objects, they are usually being used by a single view component. The component would need to rerender if either the author or isRead has changed. I don't usually need the fine grained granularity. |
Oh, really? Don't know it, thanks! And i still think that this syntax deserves shortcut :D |
@Amareis presumably this issue could be closed? It doesn't seem like there is a strong backing for adding a specific decorator. Especially as the long form version is available. |
Yep, thinks so. |
For future readers, this section now explains why it is very rarely needed to do comparisons on the output of a computed; typically the output changed anyway otherwise the computed wouldn't have run in the first place: https://mobx.js.org/computeds.html#computed-struct |
But computeds with array filter/sort is still good case for shallow comparing :D |
…underlying "computed" call. This enables caching for some situations that weren't easily possible before; for more info, see: mobxjs/mobx#2437 (comment)
There is
@computed.struct
, but there is no shallow decorator. But if computed getter returns array it may be really good to shallow compare it!Yep, computed.struct will prevent recomputing, but for big arrays of classes it will be unefficient. As I see in https://github.com/mobxjs/mobx/blob/master/src/v5/api/computed.ts it'll be three strings change.
The text was updated successfully, but these errors were encountered: