6 ms·

Any pro typescripter have any tips for how best use it in existing Node/React codebase? This article mentions material-ui and styled-components. My experience

by shroom 6y ago

Any pro typescripter have any tips for how best use it in existing Node/React codebase? This article mentions material-ui and styled-components. My experience with typescript has been cumbersome with these libraries. A lot of time is spent figuring out what ”types” to return. I find this very difficult in most cases and not fun at all. I figure there must be something wrong in my approach or in my ts config (no explicit any). In short. How to best handle styled-components/material-ui/other library in ts environment? Or is typescript just to much overhead in these usecases?

TomMarius 6y ago
Could you post some snippets with which you have difficulties?
a_humean 6y ago
I use typescript daily with libraries like those you mentioned. Typescript is not too much overhead, its a huge improvement in the overall developer experience. The main issue I've had with these libraries and typescript is compiler/IDE performance, which 3.9 seems to suggest improvements. I'm not quiet sure what issues you are facing without some examples. Given you are listing react libraries, the react community discord server might be a good place to ask specific questions. They have library and typescript specific channels to ask beginner questions in: https://www.reactiflux.com/ https://www.reactiflux.com/
- shroom 6y ago
  Thanks for your replies. Glad to hear it's working well for you. I want to learn it myself. Was hesitant to ask questions here because this is not Stackoverflow :-) I will check out the discord. Just to follow up what I meant i created a quick gist. Not working code but maybe can explain it a bit better. What I mean as an example is this. I create a function that uses styled-components. I have no idea what the return type should be at first. I must dig into internals of styled-components and eventually find something like "AnyStyledComponent" which is basically the same as "Any" but for styled-components. https://gist.github.com/slackday/7142251cf2bb3660f8c24492aa1f700d https://gist.github.com/slackday/7142251cf2bb3660f8c24492aa1... This is just one example. Just curious. Not to pick at either Typescript or styled-components which are both great!
  - bryan2 6y ago
    Not sure if there’s an @types package for this. If there’s not I recommend disabling your linter for the line and adding an entry in .d.ts. You lose effectiveness but it still works.
strogonoff 6y ago
> How to best handle styled-components/material-ui/other library in ts environment? I’m using Blueprint 3 in TS environment and it’s really nice to get feedback about, say, wrong props passed to one of its styled components right as you type. > My experience with typescript has been cumbersome with these libraries. A lot of time is spent figuring out what ”types” to return. I find this very difficult in most cases and not fun at all. Whether your code is statically typed or not, you generally have to be aware of which data structure goes where—otherwise it’s easy to break things. When code is statically typed, most things break at compile time, enabling your IDE to give immediate feedback. I find the flow much more pleasant if I don’t have to hunt down runtime errors resulting from using a library (BP3 or anything else) in a wrong way. There is some upfront effort in specifying types explicitly where compiler can’t figure it out or does so mistakenly; how fun that is might depend on your personality and established habits. In addition, I believe it heavily depends on tooling—I like using TS in VS Code environment, but TS with Vim (which I’ve been using for many years) was somewhat of a hell. Once in a while I come across an obscure library without TS typings, in which case I would generally provide a `.d.ts` file for it, starting with a catch-all `any` type for its exports, later potentially specifying it further if useful and feasible. This is by far the least fun part.
- shroom 6y ago
  Oh thanks! Yes my "problem" is mostly around what types to return or rather how to find them. To be aware that separate types package must be installed is definitely something to get into habit. I wasn't aware of the `.d.ts` files. It sounds a lot like what I was looking for! Thanks again for your feedback and help :-)
  - strogonoff 6y ago
    If finding types is especially difficult, it may depend on a particular library (poorly documented types) and on the tooling you use (e.g., VS Code allows to quickly jump to definition/implementation/etc. on any imported class or component in your code, which often takes you to the place in that library where you can find out which types you need and where to import them from; it was a bigger pain in Vim). By the way, keep in mind that it is often unnecessary to specify types explicitly because TS can infer them from context. I used to specify way too many types when I was initially learning TS.
wdb 6y ago
Yes, that’s one of my major gripes of Typescript. Once you use something like Emotion you spend a lot of time deciphering the compiler errors. I am told it will be better in the new version. Let’s see if I can find an example
johnsoft 6y ago
>A lot of time is spent figuring out what ”types” to return. Typescript infers return types, so even if you don't write out a return type, it will still be fully typed. If you still want to specify the return type, you can take advantage of IDE support. Write the function without an explicit return type, then you can hover over it to see the inferred type, then copy the type. In my preferred IDE (PyCharm), it's even easier since there's a lightbulb action for it. Alt+Enter > "Specify return type explicitly" > Enter
phamilton 6y ago
My two cents: Learn to write Typescript, not Javascript. There are Javascript patterns that just don't type well. There are other ways to write your code that will be easier to fit into the type system. It might be more verbose and less reusable at times, but it ends up being a worthwhile tradeoff. That's general advise and might not apply to the libraries you mention, but it's worked well for us to explicitly call out the differences.
jan_g 6y ago
Yes, my experience was similar (note, last time I worked with Typescript was about a year ago). It was difficult to use libraries with higher order components or just abstractions in general: redux/thunks, formik, materialui, ... I didn't want to use `any` if at all possible, but instead wanted to have properly defined types. For example, using thunks, one can pass actions directly, or functions that resolve to an action. So, when you're chaining them, it becomes fiddly with types. Compiler complaining about some type or just resolving to any type. I've spent quite some time on that one. Similarly with Formik, I wanted to have generic validators and generic way of applying those validators ... another one that cost me hours to get through and I wasn't satisfied with the result. There is a lot of information around about Typescript, also various guides like the one here: https://github.com/piotrwitek/react-redux-typescript-guide https://github.com/piotrwitek/react-redux-typescript-guide But in the end I've felt that while I've become somewhat proficient with Typescript, I was still quite slow to pump out screens and features. And honestly, I didn't enjoy working with it. (Then there is another can of worms, which is dpendencies and their typings, where it happened that some minor version was bumped and it broke the typings of another library that depended on previous one. So, you might ask, why don't you just pin the dependencies that work together? Well, sometimes an important bug is fixed in a library and you want to upgrade, but you can't, because a person unrelated to library maintainer that handles typings hasn't upgraded them yet ...)
- eyelidlessness 6y ago
  > It was difficult to use libraries with higher order components or just abstractions in general It's probably a good idea to learn how to use generics (type parameters) effectively. For me, it helped immensely to think of them as basically declarative functions in the type system, with the generic/type parameter being just like a function parameter. The cool thing is that while you have to declare them on a function, a lot of times they can be inferred at the call site. With higher level abstractions, most of the time the types just flow through these generics and you get what you want at the other side just based on inference.
- acemarke 6y ago
  Note that our new official Redux Toolkit package [0] is written in TS and specifically designed to minimize the amount of types you have to declare in your code, and we have TS-specific guide pages in each of the Redux library docs sites [1] [2] [3], and [0] https://redux-toolkit.js.org https://redux-toolkit.js.org [1] https://redux.js.org/recipes/usage-with-typescript https://redux.js.org/recipes/usage-with-typescript [2] https://react-redux.js.org/using-react-redux/static-typing https://react-redux.js.org/using-react-redux/static-typing [3] https://redux-toolkit.js.org/usage/usage-with-typescript https://redux-toolkit.js.org/usage/usage-with-typescript
kall 6y ago
> I figure there must be something wrong in my approach or in my ts config (no explicit any). This is a heretic/unpopular opinion, but I think especially for existing JS/React projects, the laxest possible TS setting is the way to go. You should be able to get to no type errors in your existing JS project with not too many changes. In these contexts (existing projects) I like to think of TS as more editor experience support than seperate language. Modern React is very friendly to TS automatic type inference, so IMHO you should be getting decent benefits from typescript without annotating anything at all. And instead of fixing complicated type errors for no real gain, just // @ts-ignore and move on. I don't know what your specific issue is with styled-components. Should work pretty much out of the box? My suggestion would be to use CSS objects over string literals because that way you get typechecking for your CSS.
- rkwz 6y ago
  > This is a heretic/unpopular opinion, but I think especially for existing JS/React projects, the laxest possible TS setting is the way to go. Not sure why you think it's "heretic/unpopular", but I think it's the only reasonable way to incrementally migrate an existing codebase to TypeScript.
  - kall 6y ago
    i‘ve read things to the effect of "if you don‘t use noImplicitAny and strictNullChecks you don‘t understand typescript" a bunch but I‘m glad to see the other approach is popular as well.
- bavell 6y ago
  IMO this is a very pragmatic approach to converting a large project from JS to TS. It's the approach I've been using to gradually convert large existing codebases over to TS without committing to a huge up-front refactor. Definitely agree with you about the IDE experience, just that alone is enough for me to justify the transition.
- outside1234 6y ago
  I used this approach in a project I migrated to TypeScript as well. My strategy was to start loose, fix those warnings, and then gently turn up the rigor when I had the energy to fix the resultant warnings.
pimterry 6y ago
> Any pro typescripter have any tips for how best use it in existing Node/React codebase? https://react-typescript-cheatsheet.netlify.app https://react-typescript-cheatsheet.netlify.app is a super detailed guide to exactly this, complete with worked examples for lots of common cases. Styled Components has a specific section in the docs on using SC with TypeScript, which might be useful too: https://styled-components.com/docs/api#typescript https://styled-components.com/docs/api#typescript

by shroom 6y ago

TomMarius 6y ago

Could you post some snippets with which you have difficulties?

a_humean 6y ago

I use typescript daily with libraries like those you mentioned. Typescript is not too much overhead, its a huge improvement in the overall developer experience. The main issue I've had with these libraries and typescript is compiler/IDE performance, which 3.9 seems to suggest improvements. I'm not quiet sure what issues you are facing without some examples. Given you are listing react libraries, the react community discord server might be a good place to ask specific questions. They have library and typescript specific channels to ask beginner questions in: https://www.reactiflux.com/ https://www.reactiflux.com/

shroom 6y ago
Thanks for your replies. Glad to hear it's working well for you. I want to learn it myself. Was hesitant to ask questions here because this is not Stackoverflow :-) I will check out the discord. Just to follow up what I meant i created a quick gist. Not working code but maybe can explain it a bit better. What I mean as an example is this. I create a function that uses styled-components. I have no idea what the return type should be at first. I must dig into internals of styled-components and eventually find something like "AnyStyledComponent" which is basically the same as "Any" but for styled-components. https://gist.github.com/slackday/7142251cf2bb3660f8c24492aa1f700d https://gist.github.com/slackday/7142251cf2bb3660f8c24492aa1... This is just one example. Just curious. Not to pick at either Typescript or styled-components which are both great!
- bryan2 6y ago
  Not sure if there’s an @types package for this. If there’s not I recommend disabling your linter for the line and adding an entry in .d.ts. You lose effectiveness but it still works.

strogonoff 6y ago

> How to best handle styled-components/material-ui/other library in ts environment? I’m using Blueprint 3 in TS environment and it’s really nice to get feedback about, say, wrong props passed to one of its styled components right as you type. > My experience with typescript has been cumbersome with these libraries. A lot of time is spent figuring out what ”types” to return. I find this very difficult in most cases and not fun at all. Whether your code is statically typed or not, you generally have to be aware of which data structure goes where—otherwise it’s easy to break things. When code is statically typed, most things break at compile time, enabling your IDE to give immediate feedback. I find the flow much more pleasant if I don’t have to hunt down runtime errors resulting from using a library (BP3 or anything else) in a wrong way. There is some upfront effort in specifying types explicitly where compiler can’t figure it out or does so mistakenly; how fun that is might depend on your personality and established habits. In addition, I believe it heavily depends on tooling—I like using TS in VS Code environment, but TS with Vim (which I’ve been using for many years) was somewhat of a hell. Once in a while I come across an obscure library without TS typings, in which case I would generally provide a `.d.ts` file for it, starting with a catch-all `any` type for its exports, later potentially specifying it further if useful and feasible. This is by far the least fun part.

shroom 6y ago
Oh thanks! Yes my "problem" is mostly around what types to return or rather how to find them. To be aware that separate types package must be installed is definitely something to get into habit. I wasn't aware of the `.d.ts` files. It sounds a lot like what I was looking for! Thanks again for your feedback and help :-)
- strogonoff 6y ago
  If finding types is especially difficult, it may depend on a particular library (poorly documented types) and on the tooling you use (e.g., VS Code allows to quickly jump to definition/implementation/etc. on any imported class or component in your code, which often takes you to the place in that library where you can find out which types you need and where to import them from; it was a bigger pain in Vim). By the way, keep in mind that it is often unnecessary to specify types explicitly because TS can infer them from context. I used to specify way too many types when I was initially learning TS.

wdb 6y ago

Yes, that’s one of my major gripes of Typescript. Once you use something like Emotion you spend a lot of time deciphering the compiler errors. I am told it will be better in the new version. Let’s see if I can find an example

johnsoft 6y ago

>A lot of time is spent figuring out what ”types” to return. Typescript infers return types, so even if you don't write out a return type, it will still be fully typed. If you still want to specify the return type, you can take advantage of IDE support. Write the function without an explicit return type, then you can hover over it to see the inferred type, then copy the type. In my preferred IDE (PyCharm), it's even easier since there's a lightbulb action for it. Alt+Enter > "Specify return type explicitly" > Enter

phamilton 6y ago

My two cents: Learn to write Typescript, not Javascript. There are Javascript patterns that just don't type well. There are other ways to write your code that will be easier to fit into the type system. It might be more verbose and less reusable at times, but it ends up being a worthwhile tradeoff. That's general advise and might not apply to the libraries you mention, but it's worked well for us to explicitly call out the differences.

jan_g 6y ago

Yes, my experience was similar (note, last time I worked with Typescript was about a year ago). It was difficult to use libraries with higher order components or just abstractions in general: redux/thunks, formik, materialui, ... I didn't want to use `any` if at all possible, but instead wanted to have properly defined types. For example, using thunks, one can pass actions directly, or functions that resolve to an action. So, when you're chaining them, it becomes fiddly with types. Compiler complaining about some type or just resolving to any type. I've spent quite some time on that one. Similarly with Formik, I wanted to have generic validators and generic way of applying those validators ... another one that cost me hours to get through and I wasn't satisfied with the result. There is a lot of information around about Typescript, also various guides like the one here: https://github.com/piotrwitek/react-redux-typescript-guide https://github.com/piotrwitek/react-redux-typescript-guide But in the end I've felt that while I've become somewhat proficient with Typescript, I was still quite slow to pump out screens and features. And honestly, I didn't enjoy working with it. (Then there is another can of worms, which is dpendencies and their typings, where it happened that some minor version was bumped and it broke the typings of another library that depended on previous one. So, you might ask, why don't you just pin the dependencies that work together? Well, sometimes an important bug is fixed in a library and you want to upgrade, but you can't, because a person unrelated to library maintainer that handles typings hasn't upgraded them yet ...)

eyelidlessness 6y ago
> It was difficult to use libraries with higher order components or just abstractions in general It's probably a good idea to learn how to use generics (type parameters) effectively. For me, it helped immensely to think of them as basically declarative functions in the type system, with the generic/type parameter being just like a function parameter. The cool thing is that while you have to declare them on a function, a lot of times they can be inferred at the call site. With higher level abstractions, most of the time the types just flow through these generics and you get what you want at the other side just based on inference.
acemarke 6y ago
Note that our new official Redux Toolkit package [0] is written in TS and specifically designed to minimize the amount of types you have to declare in your code, and we have TS-specific guide pages in each of the Redux library docs sites [1] [2] [3], and [0] https://redux-toolkit.js.org https://redux-toolkit.js.org [1] https://redux.js.org/recipes/usage-with-typescript https://redux.js.org/recipes/usage-with-typescript [2] https://react-redux.js.org/using-react-redux/static-typing https://react-redux.js.org/using-react-redux/static-typing [3] https://redux-toolkit.js.org/usage/usage-with-typescript https://redux-toolkit.js.org/usage/usage-with-typescript

kall 6y ago

> I figure there must be something wrong in my approach or in my ts config (no explicit any). This is a heretic/unpopular opinion, but I think especially for existing JS/React projects, the laxest possible TS setting is the way to go. You should be able to get to no type errors in your existing JS project with not too many changes. In these contexts (existing projects) I like to think of TS as more editor experience support than seperate language. Modern React is very friendly to TS automatic type inference, so IMHO you should be getting decent benefits from typescript without annotating anything at all. And instead of fixing complicated type errors for no real gain, just // @ts-ignore and move on. I don't know what your specific issue is with styled-components. Should work pretty much out of the box? My suggestion would be to use CSS objects over string literals because that way you get typechecking for your CSS.

rkwz 6y ago
> This is a heretic/unpopular opinion, but I think especially for existing JS/React projects, the laxest possible TS setting is the way to go. Not sure why you think it's "heretic/unpopular", but I think it's the only reasonable way to incrementally migrate an existing codebase to TypeScript.
- kall 6y ago
  i‘ve read things to the effect of "if you don‘t use noImplicitAny and strictNullChecks you don‘t understand typescript" a bunch but I‘m glad to see the other approach is popular as well.
bavell 6y ago
IMO this is a very pragmatic approach to converting a large project from JS to TS. It's the approach I've been using to gradually convert large existing codebases over to TS without committing to a huge up-front refactor. Definitely agree with you about the IDE experience, just that alone is enough for me to justify the transition.
outside1234 6y ago
I used this approach in a project I migrated to TypeScript as well. My strategy was to start loose, fix those warnings, and then gently turn up the rigor when I had the energy to fix the resultant warnings.

pimterry 6y ago

> Any pro typescripter have any tips for how best use it in existing Node/React codebase? https://react-typescript-cheatsheet.netlify.app https://react-typescript-cheatsheet.netlify.app is a super detailed guide to exactly this, complete with worked examples for lots of common cases. Styled Components has a specific section in the docs on using SC with TypeScript, which might be useful too: https://styled-components.com/docs/api#typescript https://styled-components.com/docs/api#typescript