[go: up one dir, main page]

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

history.push/replace vs react-router-redux's push #2

Open
bobmonteverde opened this issue Aug 25, 2016 · 4 comments
Open

history.push/replace vs react-router-redux's push #2

bobmonteverde opened this issue Aug 25, 2016 · 4 comments

Comments

@bobmonteverde
Copy link

Hey, first off, thank you so much for this example (as well as the other redux/firebase w/o sagas example). They seem to be a near perfect example on getting a basic/standard firebase setup inside a React/Redux project (you probably saved me days of effort just on the firebase code.... then the saga code, with a version without sagas for reference is amazing). While by no means critical, it may be worth making the 2 more consistent (ie. same action constants).

Anyway, aside from thanking you, I definitely want to pick your brain on a few things... in some cases it's hard to figure out if you are doing something in a specific way just because this example is concentrating on demoing other features and you just didn't care about certain parts... or if there are specific reasons for parts of the code.

One question I have is, is there a reason you are using history.push instead of react-router-redux's push action?

Also, is firebase-list.js based off of some other example/project.. or is it completely custom for these examples? (either way THANK YOU, it's a great piece of code I have already stolen)

Thanks in advance, and sorry for creating an issue for my questions... but I figure this being a demo repo, the issue won't be cluttering up more important ones.

@bobmonteverde
Copy link
Author

I'm also confused by your initAuth in the example. Would it not make sense to have a saga handle those calls on INIT_AUTH action (which could be a simple FSA action).

Maybe I'm missing something, and have yet to try this myself... still getting the hang of using sagas in general.

@bobmonteverde
Copy link
Author

Well, I figured out my second question... you actually did code the initAuth functionality as sagas....it just appears that you copy and pasted (or git cloned) the initAuth code, and forgot to take it out.

So, even tho your auth sagas are correct and do work.. your example is actually not using them. (Unless I am missing something, but considering I pretty much used your auth code with only 1-2 very minor tweaks, without the initAuth stuff... I'm pretty sure I'm right).

Either way, great example... the mistake actually made me pay more attention to your code, so was actually helpful.

@r-park
Copy link
Owner
r-park commented Aug 25, 2016

Hey @bobmonteverde – I'm glad to hear that this repo has been of some use to you 👍

Regarding the use of history vs react-router-redux: As you noted, parts of this repo were ported from the non-saga version. I think at one point react-router-redux wasn't part of the stack, and when I added it I neglected to replace history.push with the react-router-redux middleware.

FirebaseList was written for these demos because I wanted a light-weight wrapper that plays nicely with sagas/eventChannels (instead of working at the component level), without trying to perform too much "magic" under the hood.

Regarding initAuth(): Firebase v2 provided a convenient getAuth() method to synchronously obtain the user's auth state, whereas Firebase v3 only offers async means. initAuth() returns a promise, providing a simple way (for demo purposes) of ensuring that we have the the user's auth state before react-router's onEnter kicks in, to handle situations like browser refresh.

@bobmonteverde
Copy link
Author

Thank you so much for the clarifications... again, I can't stress how useful this demo has been.

If you don't mind leaving the issue open for a few days (considering this isn't a production package, I assume it's no big deal), I'll probably have a few additional questions. Sagas are definitely very interesting, and like most JS, there's a 100 different ways to accomplish the same task... trying to get some practice at which ways are "better"

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

No branches or pull requests

2 participants