Any plans to update to upstream 3.4

[gihrig]

Question:

I thought about giving it a try, but if you have it in your near term plans, I don't need to duplicate that work.

[jeffbski]

@gihrig That would be excellent. I have a few other things on my plate right now, so I would appreciate whatever help you can provide.

[gihrig]

@jeffbski The 3.4 conversion is mostly done 🎉

I'm not sure how to get it to your repo, since it's not based on a fork of react-boilerplate-logic. You can find it in the dev branch.

Current status:

• Mostly copy/pasted from your 3.3.3 version
• Example app works and all tests pass (on OS X w/ Chrome - not tested on Windows)
• I struggled with app/utils/test/asyncInjectors.test.js and app/containers/HomePage/tests/logic.test.js, I got them working, but you should take a look and make corrections as you see fit.
• I converted the docs, with the exception of the 'sagas' section of docs/general/introduction.md. Please have a look at this, just search for "saga" and edit as appropriate.

[jeffbski]

@gihrig That is fantastic news!

I'll get it copied over into a branch and take a look at what you have suggested.

Thanks for all your hard work on this!

[gihrig]

I see you have opened a 3.4 branch

I just pushed some changes I missed earlier, please refresh

Oops! I was mistaken. That's the upstream 3.4 branch. Too bad it's not possible to fork a fork due to name conflicts.

In any case I'm expecting to keep my rbp-340-logic project up to date with the upstream dev branch changes, and possibly some others. Is that of interest to you here?

[jeffbski]

@gihrig yeah, that 3.4 branch was just there from the original fork. That's great that you are planning to keep those branches up to date, it really help to have someone familiar with everything to do that.

I'm certainly open to your ideas on what will be the best way to maintain going forward.

I think at some point we will need to detach react-boilerplate-logic from react-boilerplate in github since forks aren't searchable unless they have more stars than the original. So as it is now I don't believe we are being search indexed either.

I don't think that prevents continuing to pull changes from other repos with git (since they were based on the same thing). Once one sets up the remotes in git it can be fetched just like any other repo.

I'd also welcome having you or any others as contributors to help us keep this moving forward. I'm still new to RBP so it makes sense to involve those with more experience with RBP as well.

If you have any ideas or thoughts on this, I'd love to hear them.

[gihrig]

forks aren't searchable unless they have more stars than the original.

Good point, didn't know that.

Once one sets up the remotes in git it can be fetched just like any other repo.

Fetched yes, but mering is another story. I have a work project based on react-boilerplate and I have been reasonably successful keeping it up to date with the source project.

This is done through separate git remotes, origin for my GH repo, which is not a fork, and upstream which is the source react-boilerplate.

My work project exists in branches based on the upstream branches. I've had pretty much mixed results being able to merge upstream branches into my main branch. Sometimes that works, sometimes it results in so many conflicts that I just open both projects in Beyond Compare and manually merge changes.

In the end it's a lot of work, but possible.

[jeffbski]

Yeah, I don't know what is the best strategy either.

[gihrig]

It works best if done frequently. The hard part comes when I get busy and neglect it for a few weeks, then the changes become overwhelming.

[jeffbski]

I've merged in your dev branch here, reviewed the files you mentioned and updated the intro doc. I think it is looking pretty good.

[jeffbski]

I also just added you as a collaborator.

[gihrig]

Thank you Jeff! 😄

[jeffbski]

You are welcome. Many thanks to you @gihrig for doing so much of the 3.4 conversion, it would have taken me so much longer since I'm new to the project. I just had to merge and resolve a few things. I guess that's why teamwork is so great.