
React-Starter-Kit – Open Source Universal React Redux GraphQL Boilerplate - reactkit
https://github.com/reactjs-starter-kit/React-Starter-Kit
======
thosakwe
Am I wrong in thinking that the fact that there are so many starter kits
(which all contain a _lot_ of boilerplate code) indicates some sort of
fundamental problem in the ecosystem?

With so much fragmentation in tooling and constant churn, it's often
discouraging to start any new project.

I've been using Parcel because of its zero-config functionality, and it always
amazes me how much boilerplate it actually takes care of for you behind the
scenes. It's a lot.

~~~
ezekg
You’re not wrong. Also using Parcel and love the fact that I can get real work
done without having to worry about build tool churn and having to configure
tens of plugins which are all badly documented.

~~~
codeaholicguy
This one using parcel, and I love parcel too
[https://github.com/codeaholicguy/rerepa-starter-
kit](https://github.com/codeaholicguy/rerepa-starter-kit)

------
tekkk
Starter kit that lacks documentation of how it works, what's it used for and
why is a bit inadequate starter kit in my mind. It's nice of you to put it out
there but I'd seriously hope you'd focus on explaining the problems you are
solving and why rather than just pumping out code like no tomorrow.

And as a personal note I think you should switch to TypeScript and Styled
Components.

------
zebnyc
For anyone interested on creating a custom starter template, I would highly
recommend Ben Awad's series on Youtube. He is a youtuber who shows how he
pieces together different starter templates. So you can follow along /
customize your templates to your own needs

[https://www.youtube.com/user/99baddawg/playlists](https://www.youtube.com/user/99baddawg/playlists)

Last year he did a very basic slack clone which has both graphql server and
client (on Node)
[https://www.youtube.com/watch?v=0MKJ7JbVnFc&list=PLN3n1USn4x...](https://www.youtube.com/watch?v=0MKJ7JbVnFc&list=PLN3n1USn4xlkdRlq3VZ1sT6SGW0-yajjL)

Lately he is heavily into Typescript and he has put together a series on how
to put together a Typescript graphql server
[https://www.youtube.com/watch?v=2eWIr6bbons&list=PLN3n1USn4x...](https://www.youtube.com/watch?v=2eWIr6bbons&list=PLN3n1USn4xlky9uj6wOhfsPez7KZOqm2V)

Currently he is putting together a series on Full stack Airbnb clone which has
both Graphql server and client (on Node) using Typescript and packaging using
yarn workspaces.

I would highly recommend all these series from a learning perspective. If you
just want to get started and learn later, you can download the code from the
referenced github repos for each series.

Edit: Watching his series has also peaked my interest in Vim

------
beeker87
Thank you for your code, I will be definitely be referring to this as I build
the base of my current project.

Diving back into Node though, just so I can get my current portfolio up to par
and job-ready, it makes me realize how broken this whole process is.

It seems like bi-annually, either Node.js is changing, Webpack is changing,
React is changing, or possibly all three have changed. What you learned just a
year ago has been modified and 'updated', usually with configuration and API
changes. This leads to a whole slew of new articles and tutorials and
boilerplate GitHub projects being created, only to be somewhat legacy less
than a year down the road.

Then the plugins you have to learn, all of which separately might have
configuration and API changes from one version to the next... Then you have to
learn server side rendering because all of this is built for the client, so
it's time to incorporate some weird page loading query string hacks to get
that working...

All of this feels like it's just one hack put on top of another, to try and
achieve what browsers have been doing since the 90's, just without reloading
the page.

I think the updates to JavaScript in ES6 like arrow functions, classes, the
spread operator, etc are great, but even this I could see going down the C++
route of just trying to add every single feature a programmer can think of to
the language.

This is why I prefer Go so heavily. The core language keywords and features
have not really changed since its inception. I hope one day this can all be
condensed and simplified, much like Go is doing for backend languages.

------
zawerf
I upvoted thinking it was this identically named project (but with 17k star)
which I've found extremely helpful in the past:
[https://github.com/kriasoft/react-starter-
kit](https://github.com/kriasoft/react-starter-kit)

------
abhisuri97
Am I the only one who wishes Starter Kits come up with a tutorial on how to
build them up from scratch?

~~~
ggregoire
Most of the work is in the package.json and the webpack.config.js

~~~
dmitriid
Yes. Most of the work is spent figuring out hell that is webpack config etc.

It would be extremely helpful to document why the configs are the way they
are. See this long twitter thread on what I discovered by ejecting create-
react-app configs:
[https://twitter.com/dmitriid/status/908677755046449154](https://twitter.com/dmitriid/status/908677755046449154)

Some highlights:

\- Because _of course_ you need to write your own webpack message formatter

\- Because _of course_ you have to manually set up listeners for SIGINT and
SIGTERM to tear down the dev server

\- Because _of course_ you have to manually write a module resolution helper
that basically replicates node's resolution mechanism

\- Because _of course_ dev server spits tons of crap, so you silence it and
manually write a custom message emitter

\- Because _of course_ you have to write your own error overlay for a dev
server

\- Because _of course_ you have to pretend your structured folders are flat
for some tools, and you have to write manual overrides

etc. etc. etc.

Simply because some poor soul spent countless hours and never documenting the
journey we have the crappy tools that we have. All these horrendously inane
configs should not be hidden behind a wrapper, but called out, created as
issues and fixed.

Because it took the webpack team several years to even acknowledge that
simplified configs with default values are a good thing. I mean, in 2017 they
said that webpack will always be crap because it can't provide defaults
because "that's how Javascript is":
[https://twitter.com/dmitriid/status/920542261020160000](https://twitter.com/dmitriid/status/920542261020160000)

etc. etc. etc. etc.

------
ggregoire
I didn't see anything related to GraphQL in this repo, whether in the readme
or in the code or in the package.json. Did I miss something or it's just
clickbait?

Also why choose Redux over Apollo or Relay if it's intended to be used with
GraphQL? Did you document your choice?

------
verdverm
[https://github.com/sysgears/apollo-universal-starter-
kit](https://github.com/sysgears/apollo-universal-starter-kit) is another I've
been working with

------
kuwze
I prefer kyt[0].

[0]: [https://github.com/NYTimes/kyt](https://github.com/NYTimes/kyt)

~~~
conradfr
At least this one makes the server part optional.

Each time I look at these bootstrap/start-kit/boilerplate projects to start a
new project I get frustrated by the intertwined client & server code, deps &
config.

------
rhapsodyv
Is there any starter kit using rest without redux out there?

Actually I’m using react with js-data for a rest backend. I have made some
simple forms and list components that abstract a lot of communication with the
server.

------
wolco
Great to see more starter templates.

~~~
ggregoire
Why that? I think the number of starter/boilerplate projects for React is
already overwhelming.

I wish create-react-app was the only one way to start a React project, but it
has its own limits:

\- not intended for server-side React apps

\- not intended for React components library

\- not intended to be used with TypeScript but Flow (could change with the
next major version tho)

Still, there are already so many alternatives, some of them just reinventing
the wheel. Do we really need another one? I'm not sure.

\- [https://github.com/facebook/create-react-
app](https://github.com/facebook/create-react-app) (50k stars)

\- [https://github.com/react-boilerplate/react-
boilerplate](https://github.com/react-boilerplate/react-boilerplate) (19k
stars)

\- [https://github.com/kriasoft/react-starter-
kit](https://github.com/kriasoft/react-starter-kit) (18k stars)

\- [https://github.com/davezuko/react-redux-starter-
kit](https://github.com/davezuko/react-redux-starter-kit) (10k stars)

\- [https://github.com/insin/nwb](https://github.com/insin/nwb) (3k5 stars,
support Preact & Inferno & components libraries)

\- [https://github.com/zeit/next.js](https://github.com/zeit/next.js) (26k
stars, server-side support, very opinionated)

\- and so on… just type "react boilerplate/starter/toolkit" on google. Most of
them are out-of-date and not maintained, making the process of choosing one
ever more overwhelming.

~~~
bpicolo
> not intended to be used with TypeScript

Microsoft maintains the Typescript plugin. Works great.

[https://github.com/Microsoft/TypeScript-React-
Starter](https://github.com/Microsoft/TypeScript-React-Starter)

~~~
ggregoire
Oh looks good, didn't know this one. But that's my point: another React
boilerplate, this one with TypeScript.

Also why they include Redux? It's not like adding Redux manually is that long
or difficult. I guess some guy who doesn't want Redux will just fork this one
and publish his own React-TypeScript boilerplate but including MobX, or some
other state management library, or none. So another one…

~~~
bpicolo
Redux isn't in the boilerplate itself I think, just in the docs for how to add
it

~~~
ggregoire
It's in the package.json.

------
williamxd3
Yet another

~~~
api_or_ipa
Tech changes. Even since react-create-app came out, there's been a ton of
adoption in GraphQL and Redux, to the point where starting a CRA app still
requires you to do pretty significant setup to get started.

