In 2019 is this article adding anything to our collective knowledge? There's nothing new here at all.
Using TypeScript with React
151–160 of 195 posts
Re: Using TypeScript with React
#152I've done 2 commercial Typescript + React projects so far (along with few side projects using what I knew that time + what I want to try). My experience been: - Discourage 'any' but not been afraid of using it when must. I think it as the 'technical debt spelled out': when you want to put down an 'any' and get on with what you're doing, by all mean, but remember its existence and make sure the team is well aware. If…
When it comes to API responses you don't control, I recommend taking a look at user-defined type guards: https://basarat.gitbooks.io/typescript/content/docs/types/ty...
Also, +1 on tslint and prettier, they're great tools.
Re: Using TypeScript with React
#153If you are going to learn a new programming language for web UI, why not go for Elm ? You get so much more than just static types with Elm.
Similar to the other commenters, I find this comparison to be a bit unfair since TS is not a completely new programming language.
Apart from that, Elm is a great language! I've been dabbling around with it in the past and I especially liked its great DX and that it's purely functional. Comparing it to ReasonML would be very interesting, too :)
Re: Using TypeScript with React
#154I've been writing Typescript with React for quite a while now and these are my feelings so far: - Typescript type system is pretty awesome, and allows the expression of some things really elegantly; in particular, string literal types are quite cool for component props that feel "htmly", union and intersection types are great for making reusable/generic components and Partial is cool for making typesafe component sta…
> - using `any` nearly always comes back to bite you as you trick yourself into feeling typesafe This. I was so frustrated with this point that I created a tool for automatic tracking type coverage on PRs called TypeCov. https://github.com/codechecks/typecov
You can avoid this dance all together by using `unknown` with more recent versions of TS. Think of `unknown` as a type-safe `any`.
Re: Using TypeScript with React
#155I've done 2 commercial Typescript + React projects so far (along with few side projects using what I knew that time + what I want to try). My experience been: - Discourage 'any' but not been afraid of using it when must. I think it as the 'technical debt spelled out': when you want to put down an 'any' and get on with what you're doing, by all mean, but remember its existence and make sure the team is well aware. If…
TypeScript + GraphQL works really well for typing API responses (assuming you’re in control of the API, of course) Disclaimer, I work for ApolloGraphQL
I do not work for apollo but I completely concur! I use absinthe on the backend with apollo on the frontend.
incidentally, there any chance of you guys releasing an ios/kotin websocket adapter for phoenix. subscriptions don't currently work because it assumes a different transport later format and phoenix is indesputably the best websocket technology I've worked with. would love to run apollo subscriptions over phoenix channels. it works great on the browser currently
Re: Using TypeScript with React
#156Typescript is a lot easier to deal with if you stop treating it as optional and do it from day 1. Avoid using the any type and things fall in to place. If it's tedious, you're probably doing something wrong or sub-optimal. Or you're just dealing with a bit of hairy old javascript that probably needs a bit of refactoring in any case. IMHO we're reaching the point where typescript (or similar languages) should be used…
Isn't it slower than node during compilation time though? I understand that there's a slight overhead on the initial setup of it already which I can plow through it but the hit on performance would be concerning cause there's already an overhead of webpack transpilation.
Re: Using TypeScript with React
#157Earlier quoted context omitted.
The way we've been using typescript is that when you're first implementing the API using 'any' is just fine, but it's not ready for release until all the 'any's are removed. What I've found is that there tends to be a happy medium between making everything 'any' at the start and never using 'any' at all that roughly corresponds to how defined our implementation is. When we're designing the implementation as we go, th…
I'm curious, and I'm prefacing this up front because I'm not always good at writing what I say in a way that may not feel like I'm coming from a good place, so here goes: Whats your testing story? This to me seems like not writing good, solid, abstracted tests before doing proper implementations of your code. This could be solved with good interface design, and perhaps be faster. I apologize in advance if this sounds…
At least for interfaces between different modules/layers of abstraction, we use BDD almost exclusively. Our docs tend to be very well defined, so 'any' isn't actually used that often. We focus on end-to-end testing over unit and integration tests, which for the REST API backend means only looking at the request, the response, and the side-effects (especially db writes). For us the docs/spec comes first and then tests, implementation, and consumer use can (and does) happen in parallel.
The REST API is defined using OpenAPI v3, and we use express-openAPI to generate request and response validator functions for every endpoint. Each endpoint needs a happy-path test for 1) every optional argument supplied and 2) none of the optional arguments supplied (if there's no optional arguments then this devolves into a single test), and all side-effects must be verified. The main place where we use 'any' or {[key: string]: any} and then just cast to what's expected tends to be the responses from the database, because the response validation code will catch any actual mismatches (the most common mismatch is forgetting to parseInt and trying to send back something like '1' instead of 1, but sometimes there's issues with the db field being nullable when it shouldn't or not nullable when it should be nullable).
Here's the latest test run on master (hope the formatting works):
---------------------------------------------------------------|----------|----------|----------|----------|-------------------|
File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s |
---------------------------------------------------------------|----------|----------|----------|----------|-------------------|
All files | 82.89 | 63.56 | 86.38 | 82.86 | |
We try to stay away from stringent TDD/BDD unit testing, because 1) the reward from the work required to get there doesn't justify the cost of getting there for us right now and 2) strict BDD/TDD unit testing makes it much harder and slower to try different implementations/refactor things, since every time you want to modify one-off helper functions you need to add a bunch of tests first. We found that cost is worth it at module boundaries (eg endpoints, auth, database), but not for most functions that are only ever called inside their module.
Re: Using TypeScript with React
#158Earlier quoted context omitted.
The problem IMHO is the old adage of the devil being in the details. I see a lot of engineers talking about things like deriving types from enums, and meanwhile the type system will merrily let you do this: type Foo = {a: number} const o: Foo = JSON.parse('null') o.a = 1 It feels like people are lulling themselves into a false sense of security by making increasingly complex self-consistence schemes via type utilitie…
This is the equivalent of casting in Java. Is Java's type system unsound?
Yes, nice article on that here: https://hackernoon.com/java-is-unsound-28c84cb2b3f
Re: Using TypeScript with React
#159Earlier quoted context omitted.
You can't cast from a HashMap to an Animal class in Java, so in that sense Java is sounder. But you can still do `Animal a = null; a.walk();`, so in that sense, Java isn't sound.
Correct me if I'm mistaken: I think you can indeed cast from HashMap to Animal and it will happily compile: ```java import java.util.HashMap; class Main { class Animal { String sound = "roar"; } public static void main(String[] args) { HashMap map = new HashMap (); Animal animal = (Animal) (Object) map; System.out.println(animal.sound); } } ``` At runtime, this will crash with the following Exception: `Exception in t…
Oh right, I totally forgot about casting to Object! So much for "sort of sound" haha
Re: Using TypeScript with React
#160Earlier quoted context omitted.
I don't think GP is criticizing the flip-flopping, but rather the "arrogantly spouting" part.
Well it's the generalisation about a large community that is the problem, whether put arrogantly or not (the arrogance only makes it harder to scroll past and ignore). GP put it well: > I'm always confused when someone calls out a large group of people for not having a consistent opinion.
The way I read OP was "given that X flip-flops, it's weird some people talk as if X is constant" (i.e. acknowledging the inconsistence in opinions and, further, calling out those that don't)