Comments (13)
Late to the party here! For context, I work with @faceyspacey :)
@dai-shi @theKashey you've done some fantastic work on this project. I've become a heavy promoter and dependent on this project, and I intend to roll react-hooks-easy-redux out to all major companies I work for. This is a substantial improvement in DX compared to react-redux!
Id love to work with you guys in whatever capacity you may have. OSS is a labor of love and I know time is always working against us all - but just this thread and the work to come from is has been really awesome - hard problems solved! It would be fun for us to work together especially as we all seem geared to tackling the exciting challenges that are a little harder to solve. We are all busy, but some effective collaboration could user in a profound new era of React development.
from reactive-react-redux.
useMemo
can be used in userland.
But as I mentioned above, to handle all scenarios with babel, and automatically do this for the user is not reliable. at the very least, it's extremely challenging to achieve 100% reliability.
dai-shi, i'm gonna be releasing docs for Respond Framework soon. I'm putting together an informal team of allstars. I want to extend you an invitation to join us. There will be 4-5 core team members. You won't have to do anymore than you want to. It could be just a badge of honor if you want. Basically I want to give credit to the fundamental work you've done here, as we do a lot to promote a beautiful new API for the Redux ecosystem. And Anton, as you know, the invitation has been extended since basically last year. Zack and I already consider you part of our team.
from reactive-react-redux.
I don't think I understand everything around the purpose of selectors, but if you want to pass deps
, I'd do something like this:
const triggerReducer = (s, a) => a || !s;
const useTriggerUpdate = () => useReducer(triggerReducer, false)[1];
export const useReduxState = (deps) => {
const lastDeps = useRef(null);
useEffect(() => {
lastDeps.current = deps;
}, deps);
const triggerUpdate = useTriggerUpdate();
// ...snipped...
triggerUpdate(lastDeps.current); // instead of forceUpdate()
// ...snipped...
};
Note that I haven't tested and I am not 100% confident.
from reactive-react-redux.
- If you will be able to get
selectors
from a some centralizedstore
- we might track their usage as well as state usage. Plus we might track state usage withinselector
. 👍 - We should be able to detect usages outside of selectors, and ask user not to do it.
- @dai-shi - selectors are a small helper functions, which does "the same" work every time. It's more predictable to use them, than randomly read from a state. They also enable deep memozation, and cuts all updates of a state, which were important, but didn't lead to a
component state
update. Example - todo list, showing only tasks assigned to me, and you are adding a task for yourself - the state is updated, todo list is updated, but "my tasks" are not.
from reactive-react-redux.
From another point of view - the initial idea was to throw aways mapStateToProps
, AND selectors
. Isn't it?
from reactive-react-redux.
If you will be able to get selectors from a some centralized store - we might track their usage as well as state usage. Plus we might track state usage within selector. 👍
Mo%$erFu$&in excellent!!
Funny thing, is i went to bed last night realizing the same thing--that the selector problem is no different than reducers once they come "from some centralized" store as you mentioned, i.e:
createStore(reducer, selectors)
Which is exactly the plan.
From another point of view - the initial idea was to throw aways mapStateToProps, AND selectors. Isn't it?
Throw away mapStateToProps
, but not selectors. But yes, move them away from having to be in every component within mapStateToProps
. And instead define them once in the "centralized" store with smart caching for use in potentially multiple components.
This means "memoization" is no longer what we want, but rather caching of multiple values, which is why I was looking deeply into your intriguing kashe library which seems to be a best of both worlds approach--those approaches being:
- cache multiple values
- prevent memory leaks via the automatic garbage collection capability of weakmaps
It seems, that this capability exists even without the added hierarchy provided by the boxed
and inboxed
additional capabilities the library provides (i.e. just by using your kashe()
function). Am I correct?
Basically, in addition to automatic proxy-based tracking, I am seeing a way to move past the reselect and rereselect problems where a selector function must be duplicated or created from a factory for every component that uses it. And therefore we can just define it once on store creation, as if we are modeling--what i prefer to refer to as--a "UI Database."
More or less like MobX + MobX State Tree, but the more pure Redux version.
Please inform me if I'm seeing clearly how to use your tools and if my plan is compatible with your great wisdom
from reactive-react-redux.
selectors are a small helper functions, which does "the same" work every time.
I understand that in general.
It's more predictable to use them, than randomly read from a state.
What does "randomly read" mean?
They also enable deep memozation
Can you simply use useMemo
?
from reactive-react-redux.
Please inform me if I'm seeing clearly how to use your tools and if my plan is compatible with your great wisdom
TLDR - @faceyspacey - you get it right.
What does "randomly read" mean?
A wild some, where you could discover everything. See below.
Can you simply use useMemo?
Divide and conquer. Use memo and "random reads" are one BIG block, which got executed as a whole. You cannot execute a part.
- memoization is not working for a big thing - some fluctuations are killing it
- it's imposible to predict how some value change would affect a "result", if that one thing got used twice.
proxyequal
is relying on selector usage, ie - if you are looking inside an object - you need value inside, not the object. Which could be false for a big things.
But splitting A THING into smaller parts, and assembling them back - you are making everything more stable, and easy to reason about.
PS: ^that^ is not a thing, if you have many small and simple components, but the first (even a single one) big one, would kill all the fun.
from reactive-react-redux.
And Anton, as you know, the invitation has been extended since basically last year. Zack and I already consider you part of our team.
invite me to the organization then
from reactive-react-redux.
The organization is called:
🙏☠ Devotion App' Development ☠🙏
picture this:
On top, instead of Guns 'N' Roses it says:
Respond Framework
on the bottom, it says:
Devotion 'App' Development
in our case, band and album name is switched (just fits better)
So we will all have skull cartoons made in Illustrator. And more importantly, we aren't an "application development team"--we are a Band, and Respond Framework is our first album!
☠'🙏' ☠
from reactive-react-redux.
I'm gonna use CrazyTalk Animator (or Adobe Character Animator) to animate a cartoon of our skulls for video tutorials
So we have a screencast of code, and then in the lower right corner is a talking skull. It should be a piece of cake with these modern tools.
from reactive-react-redux.
ps. we operate beyond all societal constructs. we dont need a taxable corporation, github organization, or anything, but to exist in our own minds and the minds of our "fans"
from reactive-react-redux.
Closing this in favor of #16 and #19. Please file a new issue for further discussion.
from reactive-react-redux.
Related Issues (20)
- Component not aware of state change? HOT 29
- Try new proxyequal HOT 19
- Stale props issue in selector API HOT 10
- Question: Ease of gradual transition to hooks concern HOT 3
- Add comparison with react-redux v7.1 in README
- Benchmarking with cocktails app by mikeyhogarth HOT 5
- Why calculateChangedBits = () => 0 HOT 16
- Discussions about proxy-polyfill HOT 1
- Benchmarking state usage tracking and other related projects HOT 5
- "Please use <Provider store={...}>..." exception unable to track down root cause HOT 3
- 'Please use <TrackedState...>' exception. Need help! HOT 6
- useTrackedState on an array does not trigger a rerender of FlatList with the extraData prop HOT 4
- Question about re-evaluation strategy HOT 9
- False negatives in tracking with React.memo
- A new API for reverting proxy
- Discussion: Antipattern to recommend `useTrackedSelector` HOT 4
- Testing Environment Slowdown HOT 4
- getUntrackedObject always returning null HOT 3
- SSR and `useLayoutEffect` issues warning in dev mode HOT 2
- Why is "patchStore" not exporte? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from reactive-react-redux.