IonContent has-subheader class not set correctly

[John Slemmer]

IonContent updates the class it will apply to its <div> via the context globals coming from IonBody (ie. this.context.ionHasSubHeaderetc.). These globals are set by the respective components (ie. IonSubHeaderBar etc.) via the ionUpdateHasX context global. This paradigm is good in theory however I think it is leading to some issues.

I have an app (https://github.com/johnslemmer/todos-reactionic-meteor) that navigates between pages that have subheader bars. What I'm seeing is that when I'm going from page A to B (both of which have subheader bars) the componentWillMount method gets called on page B (which calls to ionUpdateHasX setting subheader to true) and then the componentWillUnmount method gets called on page A (which sets subheader to false). Then when page B finally renders some of the content is not visible under the sub header bar because class="has-subheader" is not added to the <div>.

A few questions for discussion:

• Is this recreateable by someone else? I'm simultaneously working on upgrading to React 15 and want to make sure that isn't causing this issue. I don't think it is but it is worth checking.
• Is this more of a React issue that willUnmount and willMount are being called in an incorrect order? I tried googling around for this and didn't really find good info.
• Or is this more of a design paradigm that needs changing in reactionic itself? Like headers and footers being passed as properties to IonContent so it can just know then when it renders whether those things are present (I don't love this idea because I really do like the elegance of things being save at the IonBody level). Added bonus if this gets implemented then IonContent will be usable multiple times within an app (like both for the main content and maybe side menu content).
• Does this also call into question that context shouldn't be used as much as it is in reactionic. I read this https://facebook.github.io/react/docs/context.html#when-not-to-use-context and thought that maybe more things should be passed around in props where it makes sense. It seems messier but probably less buggy.
• Or should my example app change to have intermediate Layout component and another layer in my react router routes so that the subheader doesn't get re-rendered if you are staying on the same style of page (ie. a page that has a subheader). I think this is why we aren't seeing the same issue with has-header.

NOTE: I'm assuming this applies to footer and subfooter as well. Maybe even tabs too.

[Mark Pors]

I'm not 100% if I understand the issue, but my first feeling is that this is caused by having (sub)headers in individual pages and not in a shared component (like a layout component as in the kitchen-sink demo). Can you isolate the problem in a very simple bare-bone app? That makes it a bit easier to inspect.

About point 3: I used to pass these states as props all the way down in a previous version of reactionic, but that made it very unfriendly for app developers. You will have to pass props through all your components, but you shouldn't have to know anything about them.

Context is not recommended because it makes apps more messy, but for libraries like reactionic it makes perfect sense I think. React-router uses context for the same reason.

Your last point: yes I think this is indeed the case.

If you can provide a super simple empty app with this effect I'll look into it.

[John Slemmer]

Cool. Here is a concise example. https://github.com/johnslemmer/reactionic-issue-31

Switch between the two pages using the side menu and you will see some content hide behind the sub header bar.

I'm assuming this has a workaround like you expressed where I should just have another layer of layout component in the router tree. I will play around with that being a solution. If that is the way then this issue should just turn in to something that gets documented.

[John Slemmer]

Ok. Just tried the workaround. https://github.com/johnslemmer/reactionic-issue-31/tree/workaround-layout

Doesn't appear to impact anything. Take a look and see if I'm doing what you were proposing.

[Mark Pors]

Thanks for creating this "issue 31 app" :)

Now I see that the problem occurs with the side menu, I assumed you talked of normal page transitions. Looks like a bug indeed.

We have a similar issue in another app where we want to override the hasHeader etc. behavior in the app itself somehow. So that might be a solution, but we need to dig a bit deeper first.

If you have any suggestions to fix this please tell :)

[Mark Pors]

I understand now why this is happening: because of the animated entering and exiting of the pages, there is a period both pages are mounted. The leaving page sets the hasSubHeader state to false after the animation, and so the entering page gets that value as well.

Solution coming up soon (I hope)

[Mark Pors]

@johnslemmer can you check if this works for you? It's not on NPM yet, so use a local version 3.0.2 of reactionic to test.

PS make sure to do:

 <IonBody platform={platform} location={this.props.location} >

[John Slemmer]

just tested it. working great. Thanks @pors

On Thu, Apr 28, 2016 at 9:49 AM, Mark Pors [e-mail] wrote:

@johnslemmer https://github.com/johnslemmer can you check if this works
for you? It's not on NPM yet, so use a local version 3.0.2 of reactionic to
test.

PS make sure to do:

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#31 (comment)