pors / reactionic

React Ionic: We are looking for a new maintainer!

Home Page:http://reactionic.github.io/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Context isn't always up to date

johnslemmer opened this issue · comments

In React context does not always get filtered down to children if it isn't tied to a change in state or properties. This can potentially lead to bugs within reactionic because context is used heavily to pass around information about the state of headers, footers, etc.

Read this and this

One example of this can be found with this code. When the initial login screen comes up, and you do a hard refresh the has-header context information will be inaccurate and the content will slide behind the header.

I believe this issue will also show itself more when there are components that return false from React's componentShouldUpdate between IonBody and the component that wants to access context. I believe MeteorDataContainer (the component created when createContainer is called from Meteor's react-meteor-data) is one of those components that will cause this issue to be seen more often.

I'm not sure of a solution, but wanted to track the bug. I've made some attempts to try and address this, but it didn't quite work.

A way around this currently is to turn off the PureRenderMixin on createContainer. I raised an issue hoping they would document that better.

You can see the workaround implemented in this fork. I don't like it but it works for now.

Also, another workaround options that specifically for header, footer, and sub etc. information you can just add the correct has-subheader etc. in the IonContent via customClasses=. My thought is that most of the time this will be known by the component which is rendering IonContent.

@johnslemmer yeah that's a good idea. I'm still not too confident about how to make this work under all circumstances. See e.g. this code https://github.com/reactionic/reactionic/blob/master/src/components/ionBody.js#L163 that is needed for modals to work correctly if the underlying page has e.g. a footer, but the modal itself doesn't.
This might interfere with manually setting has-footer.