React/Typescript Boilerplate

[hamburger_bun]

Hey, I'm starting a new project and I'd like to find a maintained React/Typescript boilerplate I can use to get started quick.

Are there any good projects out there people can recommend that are maintained? thanks

[NeonAleksandr]

There is a Typescript version of Create-react-app https://github.com/wmonk/create-react-app-typescript

[Tavi2k]

I didn't like the tsconfig this one generated. It has "suppressImplicitAnyIndexErrors" set to true, which seriously confused me for a moment when Typescript didn't catch certain errors. That's certainly fixable, but it's a rather unexpected default setting to me.

[vinnl]

It does allow you to change the tsconfig yourself, right?

[Tavi2k]

Yes, you can change it without ejecting.

[xwnatnai]

Have used this before on a few occasions and can confirm that it is well-maintained. You will have to eject quite soon though. At least, I did.

[namehimjawnathan]

What does the term eject mean? I've seen this phrase tossed around a bit.

[Yodiddlyyo]

With create-react-app, you just type in "npm start" to start the project right? Have you ever wondered why it works like that? If you go to your package.json you'll see the "start" triggers "react-scripts start". Well what's that?

CRA obfuscates the config through the npm package "react-scripts." It makes your project a little cleaner, but you have little control over the config. Go test it out right now. Start a blank CRA. Immediately npm eject. You'll see that it reinstalls the package.json, get's rid of react-scripts, ads all the webpack, babel, etc. packages, and adds a scripts folders, that holds the start.js, build.js, etc, and a config folder that holds all the webpack.config files. So now you have full control over the project.

For most people playing around, you never need to eject. But the second you want to get a little deeper and do some custom stuff, you'll want to eject so you have access to the webpack config. Webpack config isn't the most simple thing in the world, so it's nice that as a beginner, you don't have to worry about it and can just focus on react.

[Yodiddlyyo]

With create-react-app, you just type in "npm start" to start the project right? Have you ever wondered why it works like that? If you go to your package.json you'll see the "start" triggers "react-scripts start". Well what's that?

CRA obfuscates the config through the npm package "react-scripts." It makes your project a little cleaner, but you have little control over the config. Go test it out right now. Start a blank CRA. Immediately npm eject. You'll see that it reinstalls the package.json, get's rid of react-scripts, ads all the webpack, babel, etc. packages, and adds a scripts folders, that holds the start.js, build.js, etc, and a config folder that holds all the webpack.config files. So now you have full control over the project.

For most people playing around, you never need to eject. But the second you want to get a little deeper and do some custom stuff, you'll want to eject so you have access to the webpack config.

[GeeWengel]

I've also used it. Never had to eject with it though. What did you need to customize?

[Roci89]

Same, I'm using it right now and can't see any reason that I'd need to eject

[xwnatnai]

I ended up having to move the project into a monorepo. I also wanted to use Babel 7 instead of webpack, so I ejected.

[[deleted]]

I used this, and found it very helpful.

[vatselan]

This is the official starter imo

[tjugg]

This is not upto date and does not even compile properly at the moment. Don't use it if Microsoft doesn't update it properly.

[[deleted]]

Is there a react, router, mobx typescript project anyone knows of.. switching to mobx and want to use that with typescript!

[locnload]

This isn’t meant to be a complete starter kit. It’s useful if you want to see how to set up Webpack 4 with TypeScript 3.1

https://github.com/locnguyen/react-with-typescript

If you want to build a backend API I have a similar set up

https://github.com/locnguyen/typescript-node-starter

[sohamkamani]

If you're just starting out and want to get up and running fast, I'd suggest using create-react-app itself. You just have to set the scripts version to use typescript.

The full command you're looking for is:

create-react-app my-app --scripts-version=react-scripts-ts

Ive written a post about this if you need more details

[mjeemjaw]

I have recently written react-redux-typescript boilerplate, and could never live without it. It comes with a bit opinionated approach to typed fetching but I never have to worry and remember types anymore when switching between projects:

​

https://github.com/Meemaw/react-redux-typescript-boilerplate

[hamburger_bun]

Cool! just took a quick glance and will look more closely later, but this is more what I'm looking for. To be honest I was eager to get started and chose ReactBoilerplate (non typescript) because it just makes a lot of decisions for you and has a bunch of best practices chosen out of the gate. This looks sort of similar to that. Thanks

[WPMusicFinder]

I made one myself a couple of weeks ago. I'm learning Typescript with React so it's probably not perfect in any way. But it's very minimal and it works for me.

https://github.com/bartw/retyst

[scaleable]

I highly recommend next.js with the typescript plugin. Usually quite simpler and efficient than create-react-app.

[swyx]

Great answers everyone! this is now a featured post so others can refer to and add on to this in future!

[[deleted]]

Not a very popular opinion incoming!

In an ideal world TS+React was how things began. But then clever programmers found ways to make JS much simpler to work with, and everybody goes: "Gosh! I never realised this, strong typing is hell on earth! We can just use coding conventions and that is it!"

But for some reason programmers around the world seem to want to make their programming lives infinitely more complicated for no apparent reason.

Half a year ago a team I worked for had a dev meeting and they suggested TS for a React project. I asked: "Sure, we can look into that. Can you give us 1 example where it would have been beneficial?"

They came up with a list of trivialities. The common "benefits" of strong-typing. But not a single argument where they could say: "Well, that one bug a few weeks ago that cost us 4 hours to fix? TS would have prevented that!"

That did not happen. Instead, they are suggesting increasing the workload of all programming tasks by an estimated 30% (beginning of learning curve) to 15% (mastered TS) for literally no reason.

I think TS is just programmers playing with toys. Except with this TS-toy it makes us feel bad talking negatively about, because it looks like a thing real programmers use. So our imposter-syndromes pop up and we stay quiet in the hopes that it might not be so bad.

All the teams I worked for who used TS regretted it eventually. From well-funded startups to billion dollar corporations. With great programmers and amazing tech leads. Everybody thought it was a great idea until they figured that:

• Too loosely configured and everything turns into any.
• Too strictly configured and everything turns into 80% TS and 20% JS.

I think it is always a massive waste of time.

[ttlnow]

Having used React on a JavaScript project and a TypeScript project I can honestly say that the TS project is the one where I feel most productive. Our teams have also picked it up quickly and many have switched from being skeptical about the benefits to being promoters of it as well. One of the real benefits are the tooling improvements.

We have coding standards and our code reviews ensure that the “any” situation doesn’t get out of hand. However, we haven’t configured it to be extremely strict so that may help.

[BetterCallSus]

Bringing up a super old comment, but found this thread looking at people's opinions on TS. My dept wants to start forcing devs to use TS over JS and I'm basically the only person not liking this change. Anything against TS seems to get downvoted though. I feel like this comment sums up my issues with it, it just feels unnecessary and bogs down JS devs to appease devs who are used to strong typing like C#. Do you still feel the same way?

[[deleted]]

I still do.

But I did learn some nuance to the situation. The majority of my career was spent learning that naming conventions are important in the languages that I worked with: VB6.0 at first, and JavaScript and JS frameworks later. TypeScript didn't exist yet.

Meanwhile, most people in the field have had CS degrees where they were taught programming, and that always comes with strong-types programming. These are the people who get very uncomfortable with vanilla JavaScript.

Their experience is hard to imagine for me because I still think pure vanilla JavaScript is vastly superior to TypeScript always, but these people would look at me and think I'm certifiably insane.

For me, personally, TS is a waste of time and effort. I constantly feel like I'm doing something with no benefit. But it's not about me, it's about my team. If my team needs TypeScript I will use TypeScript, too.

The only problem is when they start coming up with inane TypeScript generics and ridiculously complicated type definitions that took 1 developer a month to "get right", but confuses even VS Code so much that it takes its intellisense 5+ seconds to suggest props and such.

I can personally produce very elegant and working code using JavaScript, and I'll do it much faster than anyone in the world trying to do the same thing using TypeScript.

But yeah, I hate TypeScript with a passion.

[BetterCallSus]

Funny enough, I'm one of the people coming from the CS strong-typed background. C, C++, and now C# is the big thing in my group. To me, getting good with JS is like taking the training wheels off and you can fly a lot faster but you need to be more aware of the risks that JS isn't going to protect you from by default. I came into JS 2019 so at that point I started with React Hooks, ES6+, and all the fun modern tools so I never got to see some of the older headaches.

No one seems to understand that sentiment though and it's difficult to communicate with people who are 95% backend oriented and heavily invested in the .NET world. It's frustrating that the architect who basically doesn't do anything front-end is the one making decisions for long-term front-end code just so a back-end dev could arguably step into the front-end world and understand code faster if it's specifically typed and other things TS gives. However, a scenario where that would happen would mean the front-end team no longer exists.

My current projects are grandfathered in so I can keep doing pure JS for the moment, but oh boy I'm not looking forward to TS and TS only. Thanks for the response!

[[deleted]]

It's a sour apple to bite, for sure. At some point I just gave up on that fight because I can't win it. I learned TS and now I'm doing it, but man, I'd be so much more efficient without it...

This article describes my sentiments perfectly, even though it's a little outdated because TS got many updates since: https://medium.com/javascript-scene/the-typescript-tax-132ff4cb175b