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.

1. 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. 👍
2. We should be able to detect usages outside of selectors, and ask user not to do it.
3. @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.

@theKashey

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.