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

Update docs for using a different store key #1132

Closed
ethanroday opened this issue Dec 14, 2018 · 5 comments

Comments

@ethanroday
Copy link

commented Dec 14, 2018

  • Mark createProvider as deprecated/removed.
  • Mark storeKey in connectAdvanced() as deprecated/removed.
  • It would also be nice to add a new section detailing how to accomplish it with the new API.
@markerikson

This comment has been minimized.

Copy link
Contributor

commented Dec 14, 2018

Yeah, we're still working on updating the docs for v6 (and hopefully setting up versioned docs for v5 vs v6).

@markerikson

This comment has been minimized.

Copy link
Contributor

commented Dec 14, 2018

Out of curiosity, were you actually using that? If so, what was your use case?

@ethanroday ethanroday changed the title Update docs - mark createProvider as deprecated Update docs for using a different store key Dec 14, 2018

@ethanroday

This comment has been minimized.

Copy link
Author

commented Dec 14, 2018

It's for a Chrome extension, and it grew out of some architectural particulars there.

We have a main store in the background page of the extension that's the final source of truth for all user data. Our UI is a React app which can be inserted directly into pages as an iFrame, and there might be several instances of the UI inserted into different tabs at once. We use the excellent react-chrome-redux library to proxy the main store to all of the different UI instances, but each UI instance also has a bunch of local UI state to keep track of. Rather than make a new slice of state in the background that stores UI state separately for each tab, we just made a second store that's local to each UI instance. (Going with the former solution would also mean paying a several-millisecond cost for messaging between the UI instance and the background.)

It can be confusing at times, but it has actually worked out rather well.

@markerikson

This comment has been minimized.

Copy link
Contributor

commented Dec 14, 2018

Ah, interesting.

Does the ability to supply a custom context instance in v6 still help for your use case?

@ethanroday

This comment has been minimized.

Copy link
Author

commented Dec 14, 2018

I haven't tried just yet, but I imagine it should be workable. I can create the context and pass it to the Provider at the app level, and then just call connect with the context option. (I'm basing this on the You may also pass a {context : MyContext} option to connect part of the error message.)

Does that sound right?


EDIT:

That's working! I created a null context called LocalStoreContext and provided both stores at the app level:

 // index.ts
<Provider store={store}>
  <Provider store={localStore} context={LocalStoreContext}>
    <App />
  </Provider>
</Provider>

And I wrapped the connect() function like so (I was using storeKey before; now I'm using context):

// local-connect.ts
export const localConnect: Connect = (mapStateToProps?, mapDispatchToProps?, mergeProps?, options?) =>
connect(mapStateToProps, mapDispatchToProps, mergeProps, {...options, context: LocalStoreContext});

Then when I want to connect a component to the local store, I just do @localConnect( /* ... */ )(MyComponent) like I was already doing.

So, in the end, very little change needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
2 participants
You can’t perform that action at this time.