Is it time for an official fork?

[roof12]

This project has been very successful. It has garnered a lot of interest and helped me and many others. However, it is falling behind. Dependency versions are old and pull requests are stacking up. I don't bother to create pull requests because it is unlikely they will get merged.

This project was the boilerplate for an application of mine in production. It is not a big deal for me if this project dies. I'll update my application and move on. But we still get a lot new interest. Without too much work we could keep things current.

@erikras do you anticipate further work on this? If not, there are at least several people with write access but they haven't been very active recently. Should a few more be added? I'd be happy to help.

If we don't get any response, is there any interest in an official fork with at least several active committers?

Edit: Thanks @erikras I appreciate your work!

[jaraquistain]

I'm in the same boat; This boilerplate was vital in helping me get my app going but in the past month or so I've been checking in less and less as it gets further behind and I've been keeping things up to date on my own (and not merging back because the pull requests already exist). I'm not sure I can commit development resources towards an updated fork, but I'd be more than willing to help answer question tickets as they come in.

[alecf]

I'm anxious enough to get my pull request in that I'm also willing to help review/etc...I'm anticipating starting a fresh project from this, and I'd rather update all the packages here, rather than locally.

[sheldonj]

I'm about to start a really large project using this as my boilerplate, but I'm hesitating because some of the version numbers are pretty old. I'm pretty interested in starting from a clean slate.

[andrewmclagan]

@jaraquistain & @roof12

Im exactly in that same situation. Our project was based off this repo. We would have huge amounts to contribute back as lessons learnt from deploying to production.

• Refactored server render
• Refactored auth approach (JWT)
• Refactored redux async action creators (sagas)
• Containerized docker architecture
• New testing stack (enzyme + ava)
• Functional approach (more readable & testable)
• Reduced dependancies (76 rather then 98)
• Updated dependancies (node 5.x.x, react 15.x.x, webpack 2.x.x etc...)

[andrewmclagan]

I have merge / write access to this repo BTW. My only issue with the current repo is most of the issues raised are from newbies "How do i do this?". They belong on stack overflow. People who use a boilerplate to learn react are approaching it entirely wrong.

If you don't know what your stack does, how it works or what its dependancies do you are creating a world of pain for yourself. Go learn the ecosystem from the bottom up, THEN use a boiler plate. You will cut down your hours to production by half.

There is only one situation I would be willing to contribute to such a project:

• We lock down the issue tracker to vetted developers, only they can post issues.
• Pull requests are approached the same way, only vetted developers may submit.
• Questions and how to's are directed to Gitter channell and stackoverflow

[oyeanuj]

Appreciate all of you willing to help contribute to update the library.

I feel like I can also contribute the lessons I have learnt from creating a fairly extensive app, starting off from this boilerplate and in general, contribute back in any way I can.

@andersryanc I'd love to see some of those points that you've mentioned in the lessons learnt especially auth, refactored server render, docker, etc.

Also, to your point of closing the issues to just developers, I don't think we'll need to go that far if we can (starting now) point them towards SO and Gitter/Discord at the beginning of the README fairly clearly Currently, the FAQ sort of encourages folks to create issues for any questions. I like the approach that some other libraries take wherein you can have a clear instruction on the README and then close any issue that might come up (which doesn't happen that often). Closing 'issues' to vetted developers makes it harder for new enthusiasts, like I once was, to feel included.

And finally for, How-To's, I envision linking to or maintaining community contributed recipes could help to deal with specific sort of use-cases without overloading the boilerplate itself (react-virtualized is a good example).

[andrewmclagan]

Sure, there is allot. The server refactor is the simplest and as I was just in that headspace here is a gist taken straight from what we have:

https://gist.github.com/andrewmclagan/c4e84b0dd76e721cf75db1c06439a19b

[jaraquistain]

@andrewmclagan Thanks for that gist, My next app steps are to really clean up both the dev-flow logic and server-side stuff so it'll be a useful reference for me.

If you find some spare time the points I'd be interested in some elaboration on are:

• "Functional approach (more readable & testable)" Just like a general summary of what points were improved with functional approaches
• "Reduced dependancies (76 rather then 98)" Which ones did you drop?

[andrewmclagan]

Sure, more then happy to elaborate. Will jot it here when i have time.

[roof12]

I'm still hoping to hear from @erikras. I emailed him directly in case he has notifications turned off for this project.

If does not respond or is not interested in maintaining the project, I suggest that we proceed conservatively. There are a lot of good ideas for changing things, but the first goal ought to be updating module versions and replacing obsolete modules. After that, well, everyone has ideas but the direction is determined by the people willing to do the work.

[erikras]

Hi guys. I'm afraid I don't really have time to help maintain this repo. My OSS resources are already swamped with redux-form, which is a library that hundreds of people are actually using in production (currently at 124k downloads/month), so this boilerplate learner repo has fallen to the side.

I said as much when I anointed @andrewmclagan as a Contributor. In my opinion, the goal for this repo, going forward, should be as a solid, but minimal, collection of the best bleeding edge technologies, but not a whole kitchen sink smorgasbord of every silly little npm package that someone writes. A good example of "every silly little npm package someone writes" is multireducer, which I mostly wrote as an exercise in understanding Redux and does not belong in this repo.

This repo benefited from being one of the first to catch the Redux / Hot Reloading wave, but now there are myriad others out there. It was always meant to be a technology learning platform, and was never a versioned library to be required() into a project. I have personally cloned this repo several times to build web apps, so it is still useful for that, but yes, it needs to be modernized with its dependencies, which means fixing breaking changes of, say, react-router, as they appear.

From his comments on this issue, I'm confident that @andrewmclagan is the right person to move this repo forward...assuming he has the time. If someone would like to volunteer to help him, I think that maintaining this repo, rather than "an official fork", would be a better option.

[alecperkey]

There's at least one 'enthusiast' who forked this for a startup & has enjoyed its stack the last 3 months. So, I'm invested in fostering this repo's continued maintenance and open source fertility.

I'll start being more active with the issues and/or discord/stackoverflow.

Saying that, the discord channel invite page says it's expired: https://discordapp.com/invite/0ZcbPKXt5bZZb1Ko

Channel missing from my reactiflux dashboard also.

[andrewmclagan]

@erikras I would have answered that question for you had you not already done so haha:

I'm afraid I don't really have time to help maintain this repo. My OSS resources are already swamped with redux-form

You are doing so much good work there my friend! Keep it up.

I agree with you, I feel any focus that I put here, into a boiler plate is somewhat futile. In a sense its a great learning resource and will further the community. Although I cant stress enough that people should go off and learn react step by step. Do not jump into a boiler plate without knowing what the dependancies, methodologies and patterns are. You are just creating a nightmare for yourself.

[mmahalwy]

@andrewmclagan how can we help?

[roof12]

I don't understand how to reconcile "technology learning platform" (@erikras) with @andrewmclagan's interest in discouraging beginners. But, we'll see how it unfolds. I mostly want to see the dependencies caught up.

I'm available to help with code. I'm also willing to answer questions and close tickets.

[Fouppy]

I'd be glad to help too, I've been using this boilerplate for several projects and have updated its dependencies for them

[erikras]

I don't understand how to reconcile "technology learning platform" (@erikras) with @andrewmclagan's interest in discouraging beginners.

Different people learn differently. This repo is not a good place to start for a total React n00b, but if you've got a general grip on what React is, what Redux is, and a vague understanding of what Webpack does, but are wondering, "Okay, but what does a fully built website look like?", then this is the perfect repo to answer that question.

I, personally, discover a lot of new tech by reading through other people's source code and thinking, "What is this library being imported here?", and then investigating to understand what it does and how the pieces fit together.

When I first published it, there were very few repos that truly combined the best of the tech on offer. What I think this repo should be is a simple, fully functioning, demonstration of the current best tech.

[dlong500]

@andrewmclagan It sounds like you've done a lot of refactoring already for your own projects. Even if you don't immediately have the time to merge your changes back into this repo yourself it might be something others could work on if you set up another repo with the changes you've made. It would help a lot just to see how you cleaned things up and removed unnecessary dependencies.

[jaraquistain]

^ seconded. The thing that I generally find most useful is just pouring over someone else's implementations and using that to inform my own development choices

[andrewmclagan]

Yeah, I apologias if people have taken my comments the wrong way. The most important thing is to foster the react community, if we truly want this stack to be long lived. As @erikras mentioned, everybody learns differently. Certainly you need a level of ability in react, webpack and node in general to decipher or gain any insights from a repo such as this. A basic understanding, certainly not expert level.

Still, I strongly believe novice devs are making their life tough by building projects on a codebase they don't understand. One strength of the react community is the vast amount of learning resources around React, Redux, Webpack, ES6+.... What is a novice dev? If your unable to trace how something was implemented in this repo through the stack, then you are probably missing some core concepts.

I will start with a few small PR's over the next week or so, leave them up for review as I have merge access I wont assume they are best practice. For sure Im not going to say what we have come up with is the best way forward, although know that our stack is currently being used in production distributed across 4 machines in a docker container architecture. Handling in excess of 70,000 unique visits a day.

[richb-hanover]

@erikras @andrewmclagan Thanks for this project. As an (intermediate) noob who stepped into this project, I now understand your thoughts about using this project as a base for a full system, not as a learning tool.

One (quick) concrete thing you could do is to review the README.md to help set people's expectations about the project. I've summarized (correctly, I hope) these points from the discussion above:

About the project:

• The project is a suitable as a base for production systems. Many (dozens? hundreds?) developers have used it to build production systems that survive real Internet traffic.
• Toward that end, the pace of adding new functionality has slowed from its initial commit a year ago. Its focus is stable technologies that are reliable.
• We intend that this be a relatively minimal system. We will add important new packages that add significant benefits, but don't plan to track every little new repo that comes along.
• We will continue updating dependencies, so that cloning the project will give current, stable packages

Who should use this?

• Designed for experienced developers
• It will be a lot of work to understand the stack if you're new to React, Redux, universal apps. There are better avenues for learning these technologies.
• Please only file an Issue if you think you have found an actual bug.
• Questions ("How does this work?", "Where can I get help with ...?") etc should be asked on StackOverflow or gitter

Thanks again for all the work you've put into it.

[andrewmclagan]

Spot on, perhaps write up a PR. Very well worded.

[andrewmclagan]

One area we do need to document is the async side effect architecture. It's basically a modified thunk middleware model. It's not noted anywhere as I'm aware

[andrewmclagan]

On that note we should discuss this moving forward. Promises are great, although as applications scale redux-saga like patterns really make a difference. At the cost of understanding generator functions

[andrewmclagan]

To continue has anyone taken a look at react-boilerplate? It's by far the most concise foundation I have come accross. We could learn some lessons from them. Especially in testing and docs.

[mxstbr]

Thanks for the compliments @andrewmclagan, ping me if you need pointers for specific things.

I personally really love redux-saga and think it's going to be the future, but the generator functions tend to scare off people. Imo they'll have to learn them anyway sooner or later, so that's a tradeoff that's worth having.

[richb-hanover]

@andrewmclagan Thanks for the kind words about my summary. I must apologize that I won't have time to create a PR for edits to the README.md but please do carry on.

[anomaly44]

I could also help answering questions and closing issues. I started using this boilerplate 6 months ago for a project that's now in production, would like to see this updated and advanced further

[igoldny]

@andrewmclagan what about all the work that @bdefore have done on this project?

[jmcclell]

@andrewmclagan I will say that for seasoned developers who have learned countless frameworks in a myriad of languages, boilerplates are often the best way to glean the "best practices" as learning from the bottom up can be frustrating when we are used to being able to see the bigger picture. Given a well-made boiler plate I can generally see what's going on and begin to dissect why rather quickly, and I find it a more enjoyable way to learn when compared to simply reading docs and creating Hello Worlds at this stage. Once I understand the bigger picture, I have more context going into the details and it appears to be my preference. Just one perspective /shrug

[sunkant]

I believe that Github should have a new "issues" section which is specifically for "HOW" questions, haha.

I strongly think that there should be two "issues" sections, one for the developing / improving issues ( the present one ), and the other one for "HOW" questions, we can call it "questions".

Asking in another website for a specific project is too inefficient.

[roof12]

Here's my summary of the conversation so far:

@erikras: This project is intended to be a minimal learning platform. I don't have time to work on it. @andrewmclagan supports this vision and is in charge.

@andrewmclagan: I agree. It is not meant for beginners. I'd like to add much more, like JWT and Docker. I'll try to make some commits, but any work I do is probably wasted.

Multiple people: Great, how can we help?

[No response]

I feel bad for new people starting with this project and those submitting pull requests. I feel they would be better served if we pointed them to an actively maintained project.

If there was interest in continuing the original vision of @erikras, I could contribute meaningful work but not lead it. That path seems unlikely. Another option would be to admit that we are not a good starting point for new projects and pivot to a shared application core for those who already have applications in production. I would be in favor of that, but it would be challenging due to how much we have all diverged from master.

None of this is meant as a complaint. I have no expectations, only appreciation for all who have contributed. I just don't like the uncertainty of the status of the project.

[trungpham]

checkout this project https://github.com/choonkending/react-webpack-node
looks very clean and up to date.

[tzarger]

@roof12 It appears this project has been abandoned as the issues and PRs keep piling up... not that it is a bad thing as @erikras is doing some great work on redux-form! It seems @andrewmclagan has perhaps abandoned this project as well since he was not in favor due to the number of newbies asking questions and I am sure he is real busy too, so I am not sure he would want to be the lead on this repo. It is too bad as this project had some really great features in its time but has simply fallen behind and out of date. I would also like to say I appreciate everyone who has contributed to this project, thank you.

[brtw]

Then wouldn't this be a great time to fork? It seems that question was taken off the table, but is the cause for the whole discussion. I see that @bertho-zero made a PR with package updates and a few others have mentioned that they have kept their projects up to date. I could imagine many would like to see this project continue, as would I.

[oyeanuj]

@andrewmclagan: I will start with a few small PR's over the next week or so, leave them up for review as I have merge access I wont assume they are best practice.

Before we adopt the fork, maybe@andrewmclagan can chime in? @andrewmclagan, are you still planning to start updating this repo as per your above comment?

[casertap]

Hey @andrewmclagan can you share your work on migrating to redux-saga?

[anomaly44]

so, nobody's up to the task?

[igoldny]

checkout racket it's really nice refactor of react-redux-universal-hot-example with saga and yo built in

[xkawi]

you could check react-universal-saga, it's based on this repo for a real project that I did for my company. It has all the updated dependencies and redux-saga of course.

There are still some TODOs that I plan to implement to represent a more 'real-world' codebase, but at its state right now, it should be good enough to kick-off any production-ready project. The good thing about react-universal-saga is that, you have the flexibility and control over the codebase in however ways you want to modify it to meet your requirement.

[SunHuawei]

Find this, https://github.com/bertho-zero/react-redux-universal-hot-example
Seems @bertho-zero would keep to lead this.

[isaachinman]

@SunHuawei Not sure about that. That fork is much more opinionated than the original project, and not in a good way (imo). Databasing should be left up to the end user.

[SunHuawei]

@isaachinman, yes, agree. So, I am going to fork this and fix the out of date dependencies by myself. After that, maybe I can improve it continuously regarding the original idea - keep focus on front-end.

[tzarger]

@SunHuawei That would be awesome. It is sad that this boilerplate has been abandoned. Please let me know when you fork it, perhaps with time available, I could help out in some way.

[mmahalwy]

Since this boilerplate has been abandoned - is there alternatives anyone can suggest? This repo was beyond just getting started up and running fast but was a great place for people to share the latest trends, libraries, etc. and see it in action!

[isaachinman]

If people are interested, I can clean up my fork a bit and share it. I believe the only breaking change if you use ncu and bring all dependencies to their most current versions has to do with syncHistoryWithStore.

What I liked the most about this boilerplate was the carefully thought out architecture, but also that it remained pretty unopinionated outside of that.

[SunHuawei]

@mmahalwy, cannot agree more. Since that, it is absolutely necessary to keep the libraries right at the bleeding edge. I am willing to take this. As I said above, I will fix the out of date dependencies issue first. After that I will let you guys know. And @tzarger , sure, believe you guys would be helpful.

[oyeanuj]

@isaachinman @SunHuawei Btw, @bertho-zero's repo also has a basic-api branch which is without the new opinionated stuff. Do take a look at that, and the updates there.

[SunHuawei]

@oyeanuj , yes, there is a basic-api. I checked it just seconds ago, but it just has one change(bertho-zero/react-redux-universal-hot-example@fc3b3ff) actually. Seems he reverted all changes merged from master before that commit.

[bertho-zero]

You can also see all the changes between the original repo and my basic-api branch here: .../compare/master...bertho-zero:basic-api

and you can retrieve a .diff or .patch by adding the extension to the url above:

• .diff
• .patch

Feathersjs, for short, this is an extension of use for express services, hooks, events ... and a client to connect easily. Each parts of feathers is optional, that is why it is so light.

If you do not know feathers, I can only advise you to throw them a look.

Its purpose and application that I'm going in the direction of universal API, connectable to any database system with the management of real-time (or not), and all the aspects feathers brings. It is very intuitive, easy to understand and the documentation is pretty cool.

For those wishing to start a project from scratch with an api in node so it will be very fast to create a restful API connected to their favorite database and the client, with a very flexible authentication system (which manages eg roles), all this in the form of reusable services easily called in front.

All previous functionality are also still there, for those who want only the SSR, or only client I created the branch basic-api.