Thomas Ladd

[Thomas Ladd @TRyeLadd]

@leostera @ryanflorence I just remember having a lot of complex frontend deps (redux, apollo, formik, etc) that had high quality TS types and either non-existent or out of date flow types. A lot of the data in my apps was being handled with these deps, so really needed good types for them.

[Thomas Ladd @TRyeLadd]

@ryanflorence Don't know for sure. My guess was Microsoft probably used more third-party libs than Facebook. So more money behind making the experience with third-party libs better. @buildsghost talked some at the time about Facebook not really caring about flow's open source community.

[Thomas Ladd @TRyeLadd]

@ryanflorence I started with Flow and moved to TypeScript when all the dependencies I was using (Apollo and Formik were the main ones at the time) all had high-quality TS types and I was having to put PRs into flow-typed to try and reach somewhat parity.

[Thomas Ladd @TRyeLadd]

@ryanflorence Flow had an early advantage when TypeScript didn't support strict null checking, but once TypeScript added that in v2, TypeScript pretty rapidly accelerated in popularity.

[Thomas Ladd @TRyeLadd]

@cullophid @kentcdodds Not how the API works. You send the first 5 chars of the sha1 hash of the password and it sends back all passwords that match. You then check if the sha1 hash you're dealing with is in the returned list or not.

[Thomas Ladd @TRyeLadd]

@mjackson Probably is a downtick from the frontend desiring GraphQL as a result. The flexibility in querying data can still be a draw but probably only go for it vs tRPC/gRPC/REST if you feel the need for that flexibility vs previously there were more incentives.

[Thomas Ladd @TRyeLadd]

@mjackson In a lot of cases, frontend devs wanted GraphQL simply because these clients made their lives easier (normalized cache with automatic updates and type generation). react-query and openapi eased this some and remix/next are even more now I think.

[Thomas Ladd @TRyeLadd]

@dotansimha @TheGuildDev Thank you for making this available! Guessing it's too early to compare y'alls Conductor Gateway to the others?

[Thomas Ladd @TRyeLadd]

@mattpocockuk @kentcdodds Agreed. It would seem like with the code snippet, the ergonomics are at least about equal if not in favor of the interface/snippet.

[Thomas Ladd @TRyeLadd]

@Fesimaxu @kentcdodds https://t.co/AAFeIfhkbi

[Thomas Ladd @TRyeLadd]

@kentcdodds Obviously since it's an auth emulator, it doesn't work as a true end-to-end, but at least that logic gets relatively well tested whereas before there was nothing. Maybe there's a more general solution along those lines.

[Thomas Ladd @TRyeLadd]

@kentcdodds Yep, those are a big problem when I've tried. Also attempting to run in CI will trigger the "We don't recognize your IP, please confirm email" type of flows. Firebase ships an auth emulator that makes simulating the flows doable if you use firebase, which is the best I've seen.

[Thomas Ladd @TRyeLadd]

@_georgemoller I would just use `if/else if/else`. It's very explicit and can handle more complex logic than a simple mapping, which oftentimes is the reality.

[Thomas Ladd @TRyeLadd]

@acdlite For me, especially on larger repos, it seems like sharing the TypeScript language server doesn't work so well. Intellisense, jump to definition etc are slow or non-existant. Best pairing software I've used is @tuple.

[Thomas Ladd @TRyeLadd]

@samccone @WebReflection Recently needed to use Readability.js in node. Started with jsdom and pages typically took around 2 seconds to parse. Switched to linkedom and it was around 200 ms. Was very happy linkedom exists.

[Thomas Ladd @TRyeLadd]

@BPrengle @WSWayland Looks heavy.

[Thomas Ladd @TRyeLadd]

@andrewingram @acemarke @mjackson Biggest hang up for me has been there doesn't seem to be much out there in the way of integrating Relay with existing open source routers. The issue explorer example is the closest and has a custom wrapper around react-router-config, but bit uncomfortable using that.