Skip to content
This repository has been archived by the owner on Dec 31, 2020. It is now read-only.

Prevent rendering #50

Closed
maxs15 opened this issue May 6, 2016 · 12 comments
Closed

Prevent rendering #50

maxs15 opened this issue May 6, 2016 · 12 comments

Comments

@maxs15
Copy link

maxs15 commented May 6, 2016

Hey guys,

Is there currently any way to prevent rendering ?
I would need such a feature to optimize my server side rendering, let me explain how it works:

1/ I'm rendering my app in order to feed the stores (API call...)
2/ When all the stores are ready, I'm rendering my app a second time in order to get the final html
3/ I'm sending the html

With this feature I would be able to prevent the components rendering in the part 1/ for performance improvements ! : )
Do you think we could implement this feature ? I guess we may only have to add a condition in the shouldComponentUpdate lifecycle method ?

Thanks

@mweststrate
Copy link
Member

Sounds to me like a simple if statement in some root component that prevents children from being rendered until a certain condition is met? Or you can event postpone the SSR React.render in the first place until your stores are ready?

@maxs15
Copy link
Author

maxs15 commented May 6, 2016

Thanks for your help @mweststrate 😃

I have to render my whole component three to let the components initialize and call the necessary store's methods.

I guess I could use shouldComponentUpdate in all my "smart components" using the @observer but I don't even think that mobx-react check the component shouldComponentUpdate result before doing his own business. (Am I right?)
Having a way to enable/disable the @observer rendering would be a cool feature though, SSR would be easier, less extra code.

@andykog
Copy link
Member

andykog commented May 6, 2016

We could call shouldComponentUpdate if it exists here https://github.com/mobxjs/mobx-react/blob/master/index.js#L53 and skip forceUpdate if it returns false.

@mweststrate
Copy link
Member

@andykog good point, that might make sense anyways. Or it might be confusing :) not entirely sure. Implementing should be pretty straight forward, although the original shouldComponentUpdate should be used, as mobx replaces it with its own implementation

@natew
Copy link
Contributor

natew commented May 14, 2016

@mweststrate voting for keeping shouldComponentUpdate with it's original functionality (or at least providing an observer that respects manually written ones).

@lavrton
Copy link

lavrton commented Jun 20, 2016

Hi. This feature important for me too. My use case:
I have observer component Shape. This shape is drawing on a page in different places: in central canvas and in preview widget. Sometimes I have to update Shape very frequently. On canvas, a user needs to see real-time updates, but in preview widget, we can delay update (e.g. redraw only when the user finished drawing or only once per second). That will improve performance almost twice.

Currently, I don't see any solutions without shouldComponentUpdate.

I tried @andykog tip, looks like it works.

@mweststrate
Copy link
Member

@lavrton: observer will respect any manual written shouldComponentUpdate. However in your case I think I would create a copy of the shape to be previwed and only update that once in a while (for example using autorunAsync), that might result in less confusing code?

@lavrton
Copy link

lavrton commented Jun 20, 2016

@mweststrate will it respect shouldComponentUpdate? Take a look into this demo:
https://jsfiddle.net/lavrton/wgumzdtq/2/
Am I missing something?
Can you make any suggestions on this demo?

I am happy to use autorunAsync. But I am not sure how to do it with mobx-react. Write high order wrapper by myself instead of using mobx-react?

@mweststrate
Copy link
Member

Investigated this issue. shouldComponentUpdate is respected, but only for setState or newly passed in props. It is not respected when observables used in render are changed. This breaks fundamentally with the philosophy of MobX that derivations and state should be kept consistent with the state at all times.

If you don't want components to be rerendered, this should be expressed in the state and addressed by using for example computed or other observables that are only updated once in a while.

I hope that helps!

@thunderkid
Copy link

Hi. You said
"...It is not respected when observables used in render are changed. This breaks fundamentally with the philosophy of MobX that derivations and state should be kept consistent with the state at all times."

I'm a bit confused. Isn't the point of MobX that we can create observables, that are used in render() change them as we like, and MobX automatically tells React when to rerun render()? What exactly is the anti-pattern you're describing here?
Thanks.

@mweststrate
Copy link
Member

@thunderkid I think the discussion is about shouldComponentUpdate, not render. Not entirely sure since this thread is 1.5 years old and closed ;-)

@NgKhanh
Copy link

NgKhanh commented Aug 7, 2018

Or we could implement componentWillReact return true/false to render or not ?

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

No branches or pull requests

7 participants