Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

About redux / connect #6

Open
benzen opened this issue Jan 9, 2018 · 6 comments
Open

About redux / connect #6

benzen opened this issue Jan 9, 2018 · 6 comments
Labels

Comments

@benzen
Copy link
Contributor

benzen commented Jan 9, 2018

Being able to use redux super cool.
But I think we need an equivalent to redux-connect in order to get all the benefice of redux.

Do you plan on giving a more advanced exemple ?
If not do you know it well enought to guide someone to do so?

@caolan
Copy link
Owner

caolan commented Jan 10, 2018

I haven't used redux-connect, and to be honest I find the documentation hard to follow. It looks like it depends on react-router? In which case we'd need someone to write a router for Magery first.

I don't think it would be too difficult, and I'm happy to test / guide and add more advanced examples to the repository. Personally, I'm going to focus on the core templating libraries for now.

@benzen
Copy link
Contributor Author

benzen commented Jan 10, 2018

I sayed redux-connect but I should have sayed react-redux.
react-redux does not depend on react-router.
Agreed on the documentation is quite harsh to read.

It allow to reduce the amount of dom update to be computed or applyed to the dom.
Instead of subscribe to every change of the store and recompute the whole dom, connect let you decide, here I only need an update if theses from the store (or derived values from the store) changes.

To me it seams like the data-context would help to produce something in this idea.
But i'm not familliar enougth with with js-magery to understand if there is a way to stop the update process for the current branch.

@caolan
Copy link
Owner

caolan commented Jan 11, 2018

If you just want to filter the changes emitted from the store before calling the magery template, that should be simple to achieve outside of Magery.

If you're talking about something more complex, like using shouldComponentUpdate in React, Magery could support conditional rendering of components without issue, but there currently isn't an API for it. Any API for this would probably exist outside of the template syntax and be called as part of the JavaScript API (since conditional updates are not relevant to server-side rendering).

Perhaps if you post a short react-redux example demonstrating what you'd like to achieve I can have a look at how we might support it in Magery?

@benzen
Copy link
Contributor Author

benzen commented Jan 12, 2018

Imagine i have a page full of rendered template, base on a complexe state (stocked in a redux store).
Inside the page I have a counter for likes. This counter is fetched periodically from the backend.
On each round-trip to fetch a new value for this counter, I want the new value to appears on the page, but when this appends, I don't want to render the whole page (because this can be costly time-whise), I just the small dom reprensentation of the likes counter to be updated.

So yes this case is about something like a shoudlComponentUpdate, as you say this king of stuff only need to live on js-magery

Check this exemple
https://github.com/reactjs/redux/blob/master/docs/basics/UsageWithReact.md#componentslinkjs
What is important to notice here is that the component (the function) require three things
-active: a boolean flag to change the way the link is presented.
-onClick: a function to be called with the event
-children: an optional list of childNode to be presented inside this component.

With only this, the component will be rendered each and every time the parent component changes, from data to virtual tree. React will skip the rendering from virtual tree to dom, if it's not usefull.

Now check this part:
https://github.com/reactjs/redux/blob/master/docs/basics/UsageWithReact.md#containersfilterlinkjs

With this we will link the store with the component, a very tiny part of the store with component.
Instead of updating the whole dom on each change in the store, we will only update the parts that need to be updated(thoses for which the requried data have changed).
The trick here is that the state should be manipulated with a library of immutable data structure (like immutable.js, ramda or, maybe copykitten)

Hope this will help the conversation

@benzen
Copy link
Contributor Author

benzen commented Jan 13, 2019

Know that we have a solution for expression in data-if and data-unless.
I'm trying to work again on a simple exemple I've put together.

https://github.com/benzen/groovy-magery/blob/master/exemple/public/templates/app-root.html

In this exemple I see the thing that redux-connect is good at, and I don't see how to produce something equivalent with magery.

The attribute/data showdonetodos is passed down the tree, but only tree element care about that data.

redux-connect allow every element to access data in the store / top level context. And this allow us to not pass down every piece on information down the tree.

Do you see a more elegent way to achieve this ?

Also, maybe I use magery not in the way you intend to, and more like react. Don't hesitate to say it if it's the case.

@benzen
Copy link
Contributor Author

benzen commented Jan 13, 2019

I think what I m looking for is a special kind of component that has access to the context at the top level.

This one would be used to wrap regular component and pass them the data they miss from their parent.

So a connected component can receive data from its parent , in which case it can pass it down to its children. Plus it automatically has access to the top level context/data. It can select the data from the top level context to pass it down.

This would allow user to instanciate a component in isolation to visualise all its state at the same time. Just like devcards (https://github.com/bhauman/devcards/blob/master/README.md)

And the same component can be wired to the state of the application like it need to be. Plus we won’t need to pass down every little bit of state down the pipe.

This would be pretty equivalent to what I used to do with react and redux.

What is you take on this proposition ?

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

No branches or pull requests

2 participants