Easier access to current page metadata

[DavidWells]

I'm able to get the currently viewed page's metadata by connecting the component through redux: https://github.com/DavidWells/react-class/blob/master/web_modules/Footer/index.js#L67

Then I need to reconcile that with the current page route like: https://github.com/DavidWells/react-class/blob/master/web_modules/Footer/index.js#L14

This works but is a little tricky.

Proposal:

Add currentPage data key to the PageContainer connect

phenomic/src/PageContainer/index.js

Line 8 in 26218de

return { pages }

Then instead of my connected component I can just grab the currentPage key

function mapStateToProps({currentPage}) {
  return {
    currentPage: currentPage,
  }
}

This way I can use flags in the markdown YAML to do stuff.

The use case I am doing on reactclass is conditionally disabling the footer with this: DavidWells/react-class@2389195#diff-0f35468ff6298d982ce555b70f1de4deR4

[thangngoc89]

Usually in this situation, I'll move Footer component to Page layout. But be aware that redux will be remove soon (at least from public API).

[MoOx]

We need a better api than @connect. I think when we will replace the use of redux to react context we can provide something built-in.
I got the same use case recently.

[DavidWells]

Is redux being removed from the core of phenomic or just no longer exposed to the site?

I'm currently dreaming up some ways to make these 'static' sites in such a way that they are combined with full applications / auth.

For example:
The entire site has a store for the current page content, the application, and whether or not the user is logged in.

So basically removing the need for a subdomain app.whatever.com and simply running everything on whatever.com.

• whatever.com
• whatever.com/app
• whatever.com/blog

Is this a good idea or am I crazy?

[MoOx]

Is redux being removed from the core of phenomic or just no longer exposed to the site?

For now nothing is really decided (see #40 if you want to bring ideas).

I just think for 90% of people, a public store is not useful (eg: if you have a simple website, your are not going to add any reducers).
Phenomic data are really simple (a collection of url => page data), so we can just keep a very basic (non redux) internal store. But we will definitely offer an API to solve the use case of this issue.

Your idea is not crazy, we can think about that. Anyway, if we remove redux from public API, I think you should be able to reintroduce another store from the LayoutContainer (which we will be renamed to AppContainer).

[MoOx]

Does anyone consider this is still an issue?

[MoOx]

Closing as I didn't get more feedback on this

[morgante]

Could you please reopen this? I haven't found any good way of doing this.

The component which needs access to the current page metadata cannot be moved into a Page layout as it needs to persist across multiple pages (without ever being destroyed).

[DavidWells]

related: #772 (top level components don't have access to what PhenomicPageContainer is showing

@morgante Do you have a specific use case? Can you post links to your code as well?

[morgante]

So the specific use case I have is where several pages should share a common animated layout.

The WIP code is here. Several pages are all supposed to share this same layout. Unfortunately when you navigate to a new page the layout gets unloaded (not sure why, I think it's due to the page loading system?) and then reloaded, meaning any CSS animation progress is reset.

I've ended up having to hack it so the outer layout exists in LayoutContainer and then I'm inspecting the current route to find out which page is open. It's definitely suboptimal. Ideally, I'd be able to have the same layout reused if the next page has it (with React handling prop diffing instead of completely destroying the DOM).

[MoOx]

Like you said, layout is unmounted during loading and remounted right after.
Maybe we should allow to change this behavior so we can just update the already mounted layout.

Currently we can know in advance if a layout will be identical but in a near futur I don't know (according to the refactoring for #713) so not sure how we should handle this.
See also #587.

I don't have any specific idea atm, I am busy with the current release, but will think more about this after.

[bloodyowl]

Going to be fixed with #925

[MoOx]

Sort of fixed in master.