Skip to content
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

Typing self in actions and views: documentation advices poorly performing way #818

Closed
k-g-a opened this issue May 15, 2018 · 3 comments
Closed

Comments

@k-g-a
Copy link
Member

k-g-a commented May 15, 2018

In the documentation:
https://github.com/mobxjs/mobx-state-tree/tree/v2.0.5#typing-self-in-actions-and-views
it's said that one can use local "views" variable to refer a prop:

const views = {
    get upperProp(): string {
        return self.prop.toUpperCase();
    },
    get twiceUpperProp(): string {
        return views.upperProp + views.upperProp;
    }
  }

However, accessing such computed values (e.g. inside render method of an observed component) always leads to full recompute. This is easily prooved by tracing those properties.
Tracer says:

[mobx.trace] 'PROP NAME' is being read outside a reactive context. Doing a full recompute

Which is true, because 'views' object itself is not observed, but properties are copied to 'self' during instance initialization.

This leads to performance drop as every such property is recomputed on every re-render.
Should we add a warning to the documentation or completely remove it in favor of

const Example = types
    .model({
        prop: types.string
    })
    .views(_self => {
        const self = _self as IExample;
        return {
            get upperProp(): string {
                return self.prop.toUpperCase();
            },
            get twiceUpperProp(): string {
                return self.upperProp + self.upperProp;
            }
        };

    });

type ExampleType = typeof Example.Type;
interface IExample extends ExampleType {}
@mweststrate
Copy link
Member

Good catch! would you mind updating the readme?

@k-g-a
Copy link
Member Author

k-g-a commented Jun 18, 2018

Of course. Should I add a warning to existing example, provide the one from comment above or do both?

@mweststrate
Copy link
Member

mweststrate commented Jun 18, 2018 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants