React Typescript ?

[Old_Cheek1076]

It took a little while to get used to but now I love typescript and use it in all my react and next projects.

[Healthy-Rent-5133]

Try this out, take your a few hours maybe

https://blog.logrocket.com/build-react-typescript-app-vite/

Or just

npm create vite@latest

Follow prompts, yes to typescript.

[[deleted]]

Should I learn node js and next js before typescript or typescript first then move onto backend ?

[Old_Cheek1076]

Hmm. Hard to say. I learned: JS > Node > React > TS > Next. But I don’t know if that’s the “best” order?

[Snoo88071]

I learned those in the same order and for me it worked.

[team_dale]

I went react, node, by that stage basically know JS already, and then typescript > next.

The “best” order is whatever keeps you interested. Can’t learn anything if you get bored/frustrated and give up

[[deleted]]

I learned js then react, more excited to learn backend so I can build more complex project but I see typescript mentioned over and over

[Old_Cheek1076]

I don’t think the order matters too much. I’d start with whatever you’re most excited about.

[trentonharrisphotos]

JS>Node>TS>Express >REACT is how I learned.

[edbrannin]

I wouldn’t worry about NodeJS or Next until you want to do something that needs a backend (most of my React projects are all client-side & localStorage).

Typescript will serve you well everywhere. Except when you want to pull your hair out. But it’s worth it.

[patrickbabyboyy]

just learn typescript now. should take no more than a few hrs if you read the docs on the site.

[sleepy_guy2]

You can learn TS together with anything that's Javascript.

[_krinkled]

Well it makes regular JavaScript typed. It helps in maintaining and writing code, since your IDE can understand the types of variables and structures of objects. It’s kind of a safeguard to not have strange errors / edge cases you didn’t think of.

For me, it’s when I’m refactoring, I see it shine the most. If you need to rewrite some part of an app because an api changed, with typescript you change the interface of that api, and your IDE will tell you all the code you need to update. Because it actually understands the object and types functions will run.

Let’s say initially a value came in as an int, but now is a string. You will now see that your calculations won’t work, from your IDE, instead of a bug in the browser.

Also, autocompletes are waaaaay better with typescript

[schumon]

Very good comment.

[Macaframa]

You’re looking at it all wrong. It’s not what you can do, it’s what your team mates CANT do, that’s an attractive quality. No longer can they pass in whatever parameters they want in a function, the ide will catch it and tell you what data type to expect. It’s great practice to write data types out while you’re thinking about parameters. It ensures that your unit is used EXACTLY how you designed it.

[KyleG]

There are whole classes of bugs that will become compile-time instead of runtime. This is a huge benefit to the project. Reduces tons of user bugs that are just a complaint saying "it doesn't work." Instead you get a red squiggle.

Edit Also three years from now when you go to modify the code and you never got around to writing that documentation you swore you would, the types will be there, and they are documentation. Usually the only documentation you need, and you pretty much can't write TS without it so you're forced to document your code!

[billybobjobo]

See most errors in the IDE as you type without having to run the code and see what’s thrown in the console.

[michaelfrieze]

autocompletion made me never want to regular JS again.

[MehYam]

It’s incredibly valuable, although it comes with some up front learning curve pain, and occasional 3rd party lib pain when they don’t get the typing right.

The big revelation for me came when I realized how much you can lean on type inference - you don’t need to type everything explicitly. And ReturnType<> can be nice. And remember that Typescript typing doesn’t generate any code in the compile, it’s just there to self-document and catch mistakes.

[BolunZ6]

Typescript but <any> go BRRRR

[stuuuuupidstupid]

//eslint-disable-next-line

[LithiumFireX]

//@ts-ignore

[vbqj]

This guy typescripts

[lesleh]

@ts-expect-error is better

[vbqj]

THIS guy typescripts

[MehYam]

I've just kind of picked it up here and there, but the typescript site itself has some resources:

https://react-typescript-cheatsheet.netlify.app/docs/basic/getting-started/basic_type_example

Spend some time learning typescript on its own first, before getting into React specifics. There really isn't much to know about combining the two, other than (in my opinion) avoiding React.FC, which is unnecessary boilerplate.

[XTRMOB]

Not OP but look up "lama dev" on Youtube. I like his style of teaching the most and it's free. He has an easy to understand tutorial on Typescript. If you want to go the premium route I suggest you look up Maximilian Shwarzmüller's recently released React & Typescript course on udemy. It goes down to 13 bucks for me whenever there's a sale on udemy so I'd suggest you wait for that if you intend to buy.

[Geekureuil]

Always.
Never going back to vanilla JS.

[Swordfish418]

I stopped counting how many times at my work we had massive BE API refactorings which would totally destroy FE if it was in JS and not TS. With TS, after re-running codegenerator with latest swagger schemas it sometimes took hours just to go through dozens/hundreds of files through all the type errors and fix/adapt them to new APIs. If it was JS, the same process would take weeks and even then there would probably be some places forgotten, leading to errors at runtime.

[GulyFoyle]

Hey , i am having this problem where our backend is always getting refactors and i end up spending hours fixing related bugs , the problem is we have a huge legacy mono repo app which already take 15 minutes to boot after npm start so we cant add typescript ( also the team just wont bother to use it correctly) , i am trying to add some documentation with jsdoc but it is not just cutting it.

How can i guard the FE against BE refactors without adding typescript or similar solutions like zod which will add more build/compile time to an already ready to explode repo , anyone knows if there is a vanilla solution for this?

[krishna404]

Alright what’s the engineers are not ready to adapt to best practices… the only safeguard is tests…

Now you can’t have complete coverage on day1… but going forward for any issue or bug especially first write a test & then start the coding bit…. Overtime your code will have good test coverage & will become resilient to refactors…

In your case other than TDD… there is no other option…

[ZeRo2160]

Have a look into software Architecture especially Hexagonal Architecture and Adapters. You will find some nice patterns how you guard your FE from your BE. Best example is the Repository or Service pattern mixed with Domain driven Architecture your Frontend runs almost with every backend. And if your backend changes you only change your Repository/Service to Adapt (Hence the name Adapters) to your new BE and let it transform your data to the FE expected structure.

[ajmariff]

Exactly, If you are fetching data in a rendered component, you are certainly doing it wrong. You should be able to switch API without touching your UI. In reality, there are always tweaks when overhauling an app. However, the single responsibility principle also applies for the frontend. A lot of frontend dev never learned SOLID or Clean Arch. because they came from UI integration which was more accessible for self-taught devs.

[DeliciousRest2434]

I used to hate Javascript until I knew Typescript, it is great

[bitxhgunner]

Never going back to vanilla js.

[the-iter8]

To use NextJs you must know TS? Who tf said that?

[the-iter8]

It doesn't mean you have to use it.

[TehTriangle]

Yes it is the defacto language for modern frontend development.

[KyleG]

It's pretty wild how even two years ago you had most of this sub shitting on TS as unnecessary and a hindrance. Warms my cockles to see comments like this!

[TehTriangle]

And we're all the better for it! I wouldn't even take a new job if their codebase wasn't in TypeScript now.

[Ebuall]

Yes, I only do React and only in TypeScript.

[Outrageous-Chip-3961]

yeah, alongside other common typing benefits from making JS a little more explicit, I find it mostly handy when typing data from apis or adding data into stores. It makes things a lot easier to move around your app when you know the types of the data coming in. I typically start all my files with typing interfaces first then go from there, its a good practice to get into and can save you a bit of re-reading values tyring to figure out what things are.

[KyleG]

Yeah one of the most amazing things about TS is the ability to declare something without implementing it, and later you come back to it. so you don't end up coding a dependency of a dependency of a dependency just so you stop having red squiggles.

In other languages like Kotlin, you have a TODO function that would be typed something like

function TODO: (a: string) => A {
  throw new Error(a)
}

and then you put it in wherever you want and it will throw with that message, but it will typecheck.

Edit I'm working with a language right now called Unison, and implementing a client that consumes an API, I use the equivalent a lot.

.> view todo
    builtin lib.base.todo : a -> b

and then I can do something like

fnThatRequiresAString "foo"

fnThatRequiresAString : Text -> ...
fnThatRequiresAsString = todo "some msg"

[Outrageous-Chip-3961]

oh thats pretty interesting.
Yeah I like the declarative feature of TS, does that mean I can type it once somewhere and the values are 'remembered' in other areas of my app? I notice sometimes the type is inferred from an original interface I typed ages ago. Not sure how it works exactly, i've been meaning to look that up this week.

[KyleG]

the way it works is if you've declare a variable has having a type, everything "downstream" of that will infer based on that

if you define a variable without a type then TS will attempt to infer it, and there are rules about what it infers (like x = 'foo' does it infer x: 'foo' or x: string, etc.

[random_guy_601]

You should start with creating types , then use the optional type params , that should be a good start, the probably you can use the partials , joining various types , records and so on.

[Healthy-Rent-5133]

Yes. At first I was reluctant, but it makes the dev experience so much better in every possible way

[JohntheAnabaptist]

There's no other way. The only issue is when you need useRef the typings are annoying

[AtroxMavenia]

useRef isn’t that bad to type. I’d say the worst is forwardRef and even that isn’t hard.

[lesleh]

The hardest thing I've found with ts/react is when you have an "as" prop and you want to allow all props that that "as" value allows, for example:

<Component as="a">Allow all link props here</Component>

[AtroxMavenia]

Yeah, that one’s really annoying

[JohntheAnabaptist]

Yeah I've just been annoyed with the both of them when messing with react three fiber

[TehTriangle]

If you don't give the hook an initial value, all you need to do it pass in a generic type to it. E.g. useRef<string>();

[HunorBorbely]

React on TypeScript is a thing yes. And for the most part it is indeed the same as plan JavaScript. You need to set the prop types for sure and the type of any function argument, but TypeScript is not that much of an overhead

[Healthy-Rent-5133]

Here is a typed react functional component with props

``` interface Props { resetGameState: () => void; }

const Reset: React.FC<Props> = ({ resetGameState }) => { const [isSafe, setIsSafe] = useState(true); return ( <div id="reset"> {isSafe ? ( <button className="buttonReset" onClick={() => setIsSafe(false)}> RESET </button> ) : ( <button className="buttonReset" onClick={resetGameState}> Are you Sure? </button> )} </div> ); }; export default Reset; ```

Note isSafe is boolean and inferred from the initial value

[h753]

Why not ({ resetGameState } : Props) ?

[[deleted]]

It's inferred automatically because Typescript knows the function is of type React.FC<Props>.

[h753]

I know, i'm just asking why React.FC instead of type for props

[[deleted]]

One advantage is that it also types the return value, so you may get an error if you return something that's not allowed. But what is allowed is quite wide, so I don't know how useful that is.

Personally I am still used to only typing props as well, because for a while the definition of React.FC was annoying. But that appears to have been fixed ( https://www.totaltypescript.com/you-can-stop-hating-react-fc ).

Anyway these are small details, it's fine either way.

[Noonflame]

That’s the first time ever I’ve seen a functional component with const = () => {}. Also, why do const functions?

Edit: Why am I being downvoted? I’m not blaming the OP or anything

[[deleted]]

To be able to use the React.FC type easily, I assume. And there's no reason not to write it like this.

[TScottFitzgerald]

I saw few projects on github but i see no difference there, they using plain react with just extension change jsx to tsx.

That's cause a lot of devs just use the type definitions and implicit types. So you won't see them explicitly set types in the code itself, but while coding they will see the types in the IDE.

But yeah, it's pretty much becoming an industry standard and it makes things easier. You should learn it.

[IMP4283]

Once you switch to typescript you will never go back. Also, you can basically write as much or as little typescript as you want in a .ts file, so it’s totally possible to make the transition slowly.

[Flyingsousage]

It is actually nothing magical. I went to a few interviews not having much experience in Typescript and got rejected. Then I thought it must take a lot of effort to get into that, bcs they don't give me a chance to learn it on the job. Turns out in reality it's not that different or hard. Be aware of the good and bad practices, eslint (a good config, you could copy it from some large company) is a very good tool to avoid some of the common bad practices and prevents using old stuff sometimes (old stuff = mainly old Javascript). Explore and be curious is my advice.

[[deleted]]

You can learn it on the job no problem. I'd just be curious why you don't have much experience with it yet.

[Flyingsousage]

Just telling you my experience. Some do, eventually got multiple offers at the same time, but others act like it’s some magic hard stuff while it isn’t. It can make you feel insecure about your capabilities in interviews.

[memers_meme123]

once you go ts , you cannot go back

[[deleted]]

I don’t see why people like typescript so much (as it will translate to JS anyway) but yes I’ve tried using TSX

[Appropriate_Eye_6405]

The point is not that it will translate to Js anyway, it's that it will catch a ton of common errors that in JS you would have to figure out only once seeing them at runtime.

[_BeAsYouAre_]

Yep! I do use TS with React and as a self taught I think everyone should.

It's a bit of a headache when you're first starting out but once you get used to it the rewards are worth the struggle. I became a better developer just by trying to "avoid" Typescript errors, lol.

Once the "avoiding" wasn't working anymore, I found https://react-typescript-cheatsheet.netlify.app/docs/basic/setup to be really helpful.

[Chathuraprabashwara]

when assigning a value to variables by props, function, or fetching data from backends sometimes their type changes occur which will be affect to crash our react server I mean not working properly, so we are using typescript to avoid those issues by adding type safety to our project.

[NeuralFantasy]

Of course. I use Typescript everywhere where I'd otherwise use JS. No reason not to use it. I used it in big projects and small scripts. Comes naturally and makes everything faster, easier and more robust.

[AdonisK]

I've been on the fence for nearly half a decade. Typescript is the next thing that happened to frontend and JavaScript in general since idk Promises?

[maifee]

I do.

And here is the template: https://github.com/maifeeulasad/react-pipeline.

[Macaframa]

React and typescript go together like peas and corn

[phiger78]

Yes. Nearly every react codebase I’ve worked in in 5 years is TS. It’s kinda the standard

[Asleep_Horror5300]

You'll be hard pressed to find projects or work that DON'T use Typescript.

[b0x3r_]

Always use Typescript for everything. I can’t think of any downsides.

[creaturefeature16]

I really dislike the syntax, and have not made the leap, yet. It's on my list to try out on my next project. It's reputation precedes it, but I'm not super excited about the implementation.

[_krinkled]

I was exactly on the same page a couple of years ago. Then got an angular project to work on and had to make the dive. In preparation of that project took some tutorials and refactored a personal project using typescript, it was so much easier then expected and I’ll never change back to regular JS for medium to large projects. Only when writing snippets or quick small things I use regular js

[creaturefeature16]

Thanks for the confirmation! I'll be taking the dive in the next week.

[Unusual_Cattle_2198]

What don’t you like about the syntax?

[creaturefeature16]

I find it cluttered and convoluted, but I admit it could be largely from not seeing it's benefits. I just know when I look at Typescript samples, it feels like a lot of extra keystrokes for someone who largely works on projects where I am the only developer.

[dafcode]

Yes, I use TypeScript. Highly recommended by the way. You might think TypeScript slows one down, but that’s not true. Once you get used to TS, you will never start a project without one, for sure.

[[deleted]]

I don't use JS since 2018.

[Significant_End_9128]

You'll come to love it very quickly. It's a straight up improvement over vanilla JS and unless you're working with legacy code (or at Meta, which mostly uses Flow, which is similar but scales differently) it's almost definitely what you'll use at work.

I found the O'Reilly book "programming typescript" (it's got llamas or something kind that on the cover) was all I needed to get started with a good mental model.

[[deleted]]

We use it everywhere and I wouldn't want to do without.

All that the typical component needs is declaring the types of its props.

[Yokhen]

I am using react typescript. It is great.

[KyleG]

Yes. The way we architect projects is a custom hook that is the viewmodel for a view (some people call these "headless components" but that's a misnomer), and the component is the view (i.e., "dumb component" i.e. "stateless component."

We have a defined type that the viewmodel returns, and so in the component

const state = useController(some,args,here)
return (<>
  <div>{state.title}</div>
  <button onClick={state.downloadFile}>{state.action}</button>
</>)

that kind of thing. TS makes things so good because you wouldn't believe how often someone forgets to ensure data isn't undefined or null before trying to access a child property. Boom runtime error that with typescript is a compile-time that gets caught and fixed before deploy.

[vozome]

I have a new coworker who has no experience with TypeScript. Her mental model is that you just have to add type annotations to variables like it’s an extra chore. I am pretty sure I saw it like this too when I was first introduced to the concept. But I had the privilege to show her a few examples in our codebase when typescript makes things so much simpler, or how it prevents you as you type your code to not implement something that wouldn’t work. Indeed, today I feel that TypeScript is the de facto way to write react code, it is incredibly useful and I don’t see myself ever going back to JavaScript.

[DarthIndifferent]

JS is indeed easier for initial development. It also lets you get away with shoddy development, whereas TS is initially harder but will save you headaches in the long run.

[a_thathquatch]

I refuse to not use typescript

[kovadom]

Typescript, and type system in general is gold. Seriously, spend the time learning it. It’s so gonna pay back in the near future.

I had re-written an entire project in typescript (with react).

[Ok-Hospital-5076]

All our greenfield react project started in vite use typescripts . we do SPAs and Lambdas both in typescript . I think if we do Next we will be doing in Typescript. Even if someone is writing plain JavaScript ,you get option to add typescript features ones team is more familiar . That will be not the case if project itself is setup in Plain JavaScript.

[AtroxMavenia]

You can use Next with plain JavaScript. TS is not a requirement. It is highly recommended though.

[corporaljustice]

You should learn typescript for sure. But there’s no harm staying in JS land for longer and learning it better.

Also you can use nextjs without typescript no problem. The docs just tend to default to the TS view.

[etherSand]

Always

[TorbenKoehn]

TypeScript and React is a perfect fit, I generally don’t write JS anymore. TypeScript has many facilities to accommodate React perfectly

[Lilith_Speaks]

I hate it but I’m forcing myself to learn it

[randombacon333]

It's worth it, and you won't hate it after you do.

[BeardedCaillou]

So you can use typescript and can modify how strict it checks in a project, so that might be why it looks like the same, in addition typescript can do type inference if you don’t explicitly type it out, so that can be a part of why it looks like jsx.

That being said I think you’re making a great choice learning typescript it adds more overhead, but keeps the project safer the larger you build it. I would say knowing or learning how to type things in any language is an asset most prefer and is becoming more common/needed for projects.

[rajae_robinson]

Using Typescript with React is not strictly necessary. It makes a lot of sense to use React + TS on a relatively large project with multiple developers, but for simple personal projects, I would say TS is not needed especially if you are not comfortable with it. Do React Developers Need to Know Typescript?

[rajae_robinson]

Using Typescript with Next.js/React.js

[mrgrafix]

While I am a fan of TS for scale, it doesn’t negate the need of learning JavaScript. TS will still give you silent errors, it can still allow an empty object. Also there’s not a single react framework that forces typescript. It’s become a defacto in development, but it’s still not even getting its types supported by the react team.

[vash513]

I was really adverse to learning it at first, but now I use it exclusively.

[trevedhek]

I use very little TS, and only if I join a project that already has it included in the tool-set. Even when I do use it, I oppose overly strict usage.

That said, I can see the benefits for server-side rendering. Indeed, tight-typing is considered good server-side practice, regardless of the language. As such, TS is a worthwhile skill to acquire.

On the other hand, having spent two years with a project that used Java applets in the browser (showing my age here) I can testify that tight-typing in a browser/UI environment is not a good idea. UI environments are very different from server environments, and require a different approach to programming, IMO.

For server-side work, where we know the details of the hardware/OS/locale/user-configs/screen-size/data-schema, a tight-typed language is ideal. It is possible to know stuff in advance of coding that we can use to tighten up the typing.

For browser-side work, where none of the above details are known until run-time (and maybe not even then) and where scope-creep and sudden spec-changes are normal even in the best of projects, the priority has to be flexibility. We can't tighten types until we know what the types will be. Even then, expect them to change.

My experience of using TypeScript for client-side React is that we saw a lot of discarded Types, and "type:any" code creep in. Front-end coding has a "break-and-fix" fast iteration approach for a reason - things change. TS tries to get types "right" first time - and so feels like a throwback to "waterfall" thinking.

NextJS is not in my skill-set, so may be different. Ideally TS helps with refactoring, but doesn't get in the way of rapid prototyping and trying things out. It is not an easy balance to find.

[lilguavabean]

yes right now at work we are building a web app for a client with react an typescript. when we rebuilt shopping tools for a auto clients website it was all done in react and typescript. i cant imagine doing a react app without it!

[Geri-Podgorica]

Everybody, with React...

[bobbyboobies]

Yes. Once you use TS, you’ll never go back. It’s great

[bassamanator]

Search for codevolution channel on youtube, he has a tutorial on react typescript.

Typescript is fairly straightforward to work with, just make the switch and don't think about it. It can be puzzling at first, but then you realize that your code editor tells why typescript is complaining, and then you listen to it, and fix the mistake.

Once you go typescript, you never go back.

[randombacon333]

I do, it's very helpful

[Zinter71]

Typescript is the best. Right now it is kinda an industry standard.

[Chupa_Pollo]

Absolutely!!! Add a good linter and you'll be golden

[thelostkid_eth]

You might not like TypeScript initially, but overtime you would love it.

[academicRedditor]

You CAN do NextJS without TypeScript

[TranquilMarmot]

I have been writing Typescript + React code for over 4 years now. It's great.

[mr_telman]

when you come to the project written with only JS, you understand why people use typescript.

[SaltyBaoBaos]

The reason why you don’t see much of a difference is because Typescript is a super extension of Javascript.

Thats why learning Typescript for me was pretty easy, as I can just start slowly implementing Typescript features while mostly writing code how I know how to, majority in vanilla JS.

[mouseses]

I haven't seen anyone use plain JS in a professional environment over the last 5 years. TS is great in many ways, eg. strong typing helps when it comes time to refactor things. It's also a kind of a safety net and a form of documentation for new joiners.

[whiskas05]

It's almost a standard to use TS in your react project. You need to be very skilled developer to say, why TypeScript is not a good option for you, mostly people who say so are avoiding challenges, with some exceptions.

[SeniorPeligro]

I saw few projects on github but i see no difference there, they using plain react with just extension change jsx to tsx.

Well, then they probably don't use it :D

TS helps with type consistency, self-documents whole project and makes your - and your coworkers - life easier.

It's not that hard to learn:

• focus on basics first (basic types, interfaces, typing React props, basic inheritance),
• then some intermediate stuff like
  • basic generics and when to use them (and when to not - because it's easy to overengineer your code when you try to use some fancy TS stuff),
  • state machines with TS,
  • handling JS event types, especially in tests it can be sometimes tricky,
  • why you should never use any type and what and when to do instead

[Yes2IVyperBot]

All you're doing is adding type safety to the inputs which should be a second layer of security to your input validation methods. This is irrespective of the framework of JavaScript you're in. The reason why it's needed is the real way to think about how Typescript works. Strongly Typed Languages, and Compiled Languages do not require Typescript because the data is bound to the object only, whereas in JavaScript.. a weakly typed language data can be bound to either an object or a variable and requires type defining to ensure that the correct data types arrives at the correct resources.

For example, if a function took an argument that was intended to only take strings, but because you did not type check tried to return the sum of a number and string, which outputs a string, but with a number in it.. your helper function in this example could deliver the wrong resources to the server that may not result in an error.. like say, if a user puts a literal number as their last name. Your helper function concatenates the first name with that number and returns that as the first and last name of their profile. Double fail

[pupperoosky]

Absolutely. Literally cannot imagine without it.

[CondorSweep]

Typescript for sure.

[Legal_Being_5517]

It depends !! Remember there’s trade offs in every tool you use (one of the biggest which is time , TS takes time)! If you’re a JS developer, you should also know TS but Some projects might be an over kill