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

Easier access to current page metadata #471

Closed
DavidWells opened this issue May 14, 2016 · 12 comments
Closed

Easier access to current page metadata #471

DavidWells opened this issue May 14, 2016 · 12 comments

Comments

@DavidWells
Copy link
Contributor

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

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
Copy link
Contributor

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
Copy link
Owner

MoOx commented May 16, 2016

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
Copy link
Contributor Author

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
Copy link
Owner

MoOx commented May 17, 2016

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
Copy link
Owner

MoOx commented Aug 23, 2016

Does anyone consider this is still an issue?

@MoOx
Copy link
Owner

MoOx commented Aug 31, 2016

Closing as I didn't get more feedback on this

@MoOx MoOx closed this as completed Aug 31, 2016
@morgante
Copy link

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
Copy link
Contributor Author

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
Copy link

morgante commented Sep 21, 2016

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
Copy link
Owner

MoOx commented Sep 21, 2016

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.

@MoOx MoOx reopened this Sep 21, 2016
@bloodyowl
Copy link
Contributor

Going to be fixed with #925

@MoOx
Copy link
Owner

MoOx commented May 11, 2017

Sort of fixed in master.

@MoOx MoOx closed this as completed May 11, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants