Hacker News Reader

Comment by eyelidlessness | Hacker News Reader

The problem with the premise of the article is that it presupposes that a library’s interfaces will, and ultimately must, be complex. The great thing about TypeScript for library development, if you start with types, is that it strongly encourages you to create simpler and less flexible interfaces. That’s not to say you don’t sometimes need (or won’t sometimes choose) to use some of TypeScript’s more complex features. But a lot of the time you won’t, or should think seriously about whether your interfaces are becoming too complex.

Much of the complexity of TypeScript’s type system is a direct result of excessively dynamic interfaces in existing, untyped JavaScript. Starting with types is a good way to catch that early, rethink the interface, and either isolate it or avoid it entirely.

View on HN

I'll agree, and disagree.

I made a similar comment in 2019 about "TS pushes you towards simpler APIs" [0], so I agree that it's both a good thing in principle, and something TS usage leans towards in practice.

At the same time... JS _is_ a very dynamic language, library design reflects that, and library code by its very nature must account for the different ways that users will want to call it. That causes library types to be much more complex than app types.

[0] https://blog.isquaredsoftware.com/2019/11/blogged-answers-le...

"JS _is_ a very dynamic language, library design reflects that"

I would argue it should not. If your API cannot be well expressed in the Typescript type system, it is your API that should change.

Yup.

Especially since types are documentation. If you are using some meta dynamic type garbage, then I as a user of the API am left to wonder "Ok, this takes <U, K extends keyof U>... WTF is it expecting?"

This isn't to say that sort of thing is ALWAYS wrong, but rather it should be the exception and not the rule.

You do types because constraints make code clearer. By having a BF compiler in the middle of your template definition, you've defeated the types and you might as well put an `any` there with docs that say "here there be dragons!"

This is all well and good until you have to deal with other code and other APIs in your library (results from network requests, localstorage, untyped javascript libraries, etc.)

I'd rather not warp my whole project around a typing system if I don't need to. I also might not be the owner of every API I need to consume...

I think TS is great in certain cases- I love being able to get intellisense info from TS. When I download a new library and I get those helpful hints built right in from the libraries TS adoption, I love it. Typescript in this instance is reducing friction in my development workflow.

In my day job I work at an agency where we rapidly deliver a lot of new web properties. I have used Typescript on projects when it was a client requirement, but in our environment using Typescript generally feels like it overall adds friction and time to the project. Some team member inevitably gets stuck spending a bunch of extra time working with TS stuff: setting up the project with proper rules, writing some complex interface to deal with some random API we are either consuming or creating ourselves (in which case it is usually under rapid prototype development and needs to be updated constantly), etc.

I'm sure it is very helpful when working at scale with tons of developers on a highly stable and established project, but in my opinion it isn't generally applicable to every web property that it would be better on Typescript; it really depends on the scale of the project and the scale of the team maintaining it.

> I'd rather not warp my whole project around a typing system if I don't need to.

This sounds to me like MongoDB advocates like "psh! who needs a schema! don't slow me down, I'll just dump JSON into the database however I like." The types exist whether you write them down or not.

I agree with you that TS might not be great for everyone and every use case. But maybe you should just use `any` some more!

Every field in a MongoDB document (we encoded documents in BSON at the driver level) is typed and you can apply a schema to any collection if you choose to do so.

Python is also very dynamic, yet libraries rarely allow arguments to be number/string/list/dict/function at the same time.

Yet in JavaScript I see this all the time - pass a string URL, but we also accept a function which will return a string URL, or maybe an option object - { url: string, strict: boolean }

So I think it's more of a culture thing.

Luckily these types are not complex at all to type in Typescript. You just enumerate all the options with a | character separating them.

Right, but people compose. They take this union and put it in another object, which also allows multiple types for some field, and then they take that object and put it in another one, and then you have a 10 line type declaration for 3 fields.

Which is why you can have aliases for those types, each level of abstraction can be nicely wrapped up. It just describes the reality.

I’m mostly sitting this out, but I’ll interject here because this is wrong. Union types are often used as an XOR (a | b as “either a or b, but not both”), but they’re an inclusive OR (Partial<a> & Partial<b>, as “some parts of a or b, the parts they share guaranteed”) which is almost never what anyone wants when dealing with objects. The pain is that you can’t distinguish them without a narrowing factor, and if you can’t the types are horridly complex.

I mean, that makes sense. If types `A` and `B` both have a function `doStuff`, is it bad to be able to do `x.doStuff()` without narrowing?

For example: every object’s prototype chain ends with `Object.prototype`, so all objects have a `toString` function. I shouldn’t be forced to narrow my `number|bigint|string` (for example) just to do `x.toString()`. If I was, we’d get this ugly and bloated mess:

    function callToString(x: number | bigint | string)
    {
        if (typeof x === "number")
            x.toString();
        else if (typeof x === "bigint")
            x.toString();
        else
            x.toString();
    }

Regardless, they’re just copying JavaScript’s duck typing feature. It’s not much different than languages like Java and C# that have interfaces. In C#, if my parameter is IClonable, I don’t care what it is, but know there’s a `Clone()` method attached to it.

Python libraries kind of used to do this more, but seem to be doing it less now, in part because highly-polymorphic interfaces are a huge ugly pain in the butt with the Python type hinting system.

What's so painful about writing

   foo: int | str

It gets a lot more complicated than that. One of many, many examples: https://github.com/pandas-dev/pandas-stubs/blob/v1.4.3.22082...

In general, if someone with experience in a domain is complaining that something is hard, it's safe to assume that the thing is actually at least kind of hard, and that they aren't just a crybaby about indentation and formatting.

I don't see what's complicated about this example. It adds overloads, but those aren't hard, either.

Fair, it's not "hard". But I stand by my assertion that it's a huge ugly pain in the butt. That doesn't mean it's not worth doing, but that doesn't make it less huge, ugly, or painful.

I also assert that if NDFrame.loc were less polymorphic (e.g. if you had a separate accessor like NDFrame.mask for boolean subsetting) it would be easier to use, easier to reason about, easier to teach, easier to document, and easier to write type hints for.

The worst situation is when you want to have multiple return types depending on the argument values, like Pandas' inplace=True. Putting aside the problem of dependent types, even supporting only literal True and False requires you to write out every single overload twice, creating a literal combinatorial explosion of overloads.

And that's also ignoring the whole world of parametric polymorphism required for higher-order functions, factory functions etc.

Maybe the situation is no better in something like C++, but I don't know enough C++ to have an opinion on it.

To be fair, there are few things as here-be-dragons as the guts of Pandas. It'd be hard to find a more rarified example, but it served to further the conversation at least.

> Python libraries kind of used to do this more, but seem to be doing it less now…

I’d argue that it has to do with C extensions making it a lot of work to get it right.

Some library code does it (which is where I learned how to do it ‘correctly’) but in general, run of the mill code it is pretty rare. Just something like an overloaded __add__ turns into a page and a half of code and there’s a lot of functions in the numbers protocol struct.

Labor of love really.

Yikes! Why bend over so much for clients of the library?

Because the whole point of a library is to be useful to its clients.

> JS _is_ a very dynamic language, library design reflects that

This is mostly an issue if you're tacking on those types on top of your existing design, rather than starting your design from your types, no?

I think allowing people to call functions in a vast variety of ways is a mistake. It's one of the things that frustrates me the most about the javascript ecosystem, it's hard to figure out the call signature for any given function because there's like 15 different ways to call it. I'd argue it's better to just have one well documented way. It's not even like there aren't patterns for it, ie passing an "options" object or something like that (although even then I think that can be an antipattern unless there truly needs to be a variety of options -- ie a db connection or something. Better just to have multiple functions with specific purposes instead of one mega function that does everything)

Agree, 100%. Make your function definition `foo(foo: Foo)` not `foo<T extends comparable | int | Bar>(foo: T)` Flexibility is the enemy of a type system and library design in general.

I don't think allowing users to call libraries in all manner of crazy ways is a good thing at all, and I don't think anyone would really be that put out by following a more pythonic approach of just allowing one way to do something.

Yeah but you're writing libraries in Javascript, that ship has sailed already. You're gonna just need a bit fat switch statement to check your input types on every public function you ever write.

It's never too late to stop making bad designs. I've written plenty of (internal) libraries and if someone asked me to put in a big fat switch statement I'd ask them why they need it.

We’re talking about typescript here

Case in point, over the weekend I tried creating an npm package for a custom hook. Since it's public-facing, I wanted to use TS so I could expose types for users.

Part of this hook is that users can pass in custom data. I tried to create a type that was basically "an object of any string key, with the type value". Gave up after like an hour of banging my head against my desk. Maybe I'm new to TS, but FFS it should not be that hard to do.

Fortunately that's not too difficult:

  let x: {[key: string]: Type}

But maybe the documentation is lacking here?

For the record, this is equivalent to:

  let x: Record<string, Type>

Pun intended.

We were trying to add types to some of our code. And the types were getting ridiculously convoluted. And at that point it was like - maybe it's not the types that are the problem, maybe it's the interface that needs to be rewritten.

The OP's example of createActions smells like such a scenario. The way redux mashes up payloads and discriminators makes it hard to type correctly - as in objects are not simply composed, they're extended by adding properties, and for no immediately obvious reason (which might be because of my inexperience, granted).

Had redux been developed in typescript from the start, I doubt it would have chosen this API. Then again, the current version is already in typescript, so perhaps that optimism is unwarranted; unfortunately my experience with it is years ago already.

This particular use case is trying to strongly type the "Flux Standard Action" object shape. An object _may_ have a `payload` field for its data, _may_ have an `error` field that indicates this action represents an error, and _may_ have a `meta` field that provides additional descriptive information.

This isn't part of the Redux core package, but it's a convention the community adopted shortly after Redux became popular. Redux Toolkit uses that as the standard structure for an action object. `createAction` defaults to just `{type, payload}`, but you can optionally provide a callback that adds the other `meta` and `error` fields. So yes, there's some additional complexity here because of the optional field contents, and this type is telling TS what the final type should look like based on which fields exist.

Note that as an end user, you normally don't even call `createAction` yourself - it's automatically called as part of our `createSlice` API. What end users normally write is:

  export const counterSlice = createSlice({
    name: 'counter',
    // `createSlice` will infer the state type from the `initialState` argument
    initialState,
    reducers: {
      increment: state => {
        state.value += 1
      },
      // Use the PayloadAction type to declare the contents of `action.payload`
      incrementByAmount: (state, action: PayloadAction<number>) => {
        // `action.payload` is now a `number`
        state.value += action.payload
      }
    }
  })

Care to share more details about code smell patterns you noticed?

It was bad the first few years, with existing code being hard to type because it was creatively written. But now that almost everything is somewhat typed, JS has converged to a way of writing code, and you should consider the tradeoffs before choosing a different path than the current norm.

I really _wish_ this were true, but go look at a vareity of "modern" React projects. React is so flexible that I've seen nightmare implementations of what could be reduced to just a few short lines. Then people turn around and blame React as a 'garbage framework'. Then if you talk about a much more verbose and strict framework like Angular, people turn around and complain "I can't do what I want with this overly opinionated framework!"

Damned if you do, damned if you don't.

However, if you look behind the curtains of these infamous gripes (some of them so often repeated they are cliché), 99% of the time its people who just haven't spent enough time around a certain framework or language and go create a rant post (similar to OPs post)

You're free to love the tools and languages you use all the time. But it's bad practice to go around bad mouthing tools and frameworks you don't full understand or haven't used productively.

It also was missing a lot of crucial features early on, which made typing certain things impossible. Even now there's a few things that are a PITA to type, but as you say those edge cases can be largely avoided.

Agree 100%. Redux et al are terrible examples where complexity is through the roof, these libraries were written way before TypeScript was the norm. You can eliminate almost all of that by having simpler interfaces, but that requires a different API built with types in mind.

I agree, and it’s the same with Python. If you start with static, type-safe first, then Python’s flexibility ends up being so horribly convoluted that you avoid it in favor of simpler constructs. **kwargs? Massive union types? Super flexible dicts? Rather not!

I’ll define 50 strongly typed constructs over having to run my code through 50 times to catch all the runtime bugs.

I have found *kwargs useful for wrapper functions, where you pass kwargs to some other, later defined, function.

Agreed! From the article:

How do library developers debug their highly dynamic and heavy use of conditional types, overloads?

Don’t do that. It dramatically increases compile time and results in a maintenance nightmare. Keep types primitive.

In my own code I use type unions of primitives and/or named types. For objects I use interfaces. With that I am able to provides types for about 98% of my code. That left over 2% is generally for extending the global Array type or extending an event.

Yeah, Redux Saga is known for heavily using JS generators and I wonder how much of this is just the relative obscurity of that language feature for him. It's not exactly a straightforward library.

Here's a perfect example. I maintain a simple Node library designed to connect to Apple's App Store Connect API. https://github.com/dfabulich/node-app-store-connect-api

It accepts, as a parameter, a URL for Apple's REST API. My library handles authentication, and returns the parsed JSON result, with a handful of tweaks to make the API more usable in JavaScript.

Depending on which URL you request, you'll get different result object back. You could get a single object in response, or an array of objects, and the type of returned objects is different for each URL type.

How would you add TypeScript types to this API? Well, Apple provides an OpenAPI documentation of all of their URLs, which I could use to autogenerate types, but then, how would I handle all of those types in response to the user's string input?

Well, it turns out that TypeScript is so amazingly fancy that you can write very clever code to parse strings at compile time, extracting parameter types etc. from string literal types. https://lihautan.com/extract-parameters-type-from-string-lit...

The documentation explains how an API like this:

   app.get('/purchase/[shopid]/[itemid]/args/[...args]')

can parse its parameters into a Request type with shopid, itemid, and args[] array parameters. This would catch a bug if you had a typo, e.g. "itmid".

But the code to do that looks like this:

    type IsParameter<Part> = Part extends `[${infer ParamName}]` ? ParamName : never;
    type FilteredParts<Path> = Path extends `${infer PartA}/${infer PartB}`
    ? IsParameter<PartA> | FilteredParts<PartB>
    : IsParameter<Path>;
    type ParamValue<Key> = Key extends `...${infer Anything}` ? string[] : number;
    type RemovePrefixDots<Key> = Key extends `...${infer Name}` ? Name : Key;
    type Params<Path> = {
    [Key in FilteredParts<Path> as RemovePrefixDots<Key>]: ParamValue<Key>;
    };
    type CallbackFn<Path> = (req: { params: Params<Path> }) => void;
    
    function get<Path extends string>(path: Path, callback: CallbackFn<Path>) {
        // TODO: implement
    }

Nifty, eh? But, as the article says: how would you test this code? How would you debug it?

Clearly, I wouldn't do that. Instead, I'd write a script to autogenerate individual methods, e.g. instead of get(`apps/${appId}`) that returns a parsed JSON blob, I'd autogenerate a getApp(appId) method that returns an App object.

But that API isn't any simpler than the API I already have; it's just different.

And let's not forget that I'd have to write a script to autogenerate these methods (or just their types) based on Apple's OpenAPI specification, and now I have to maintain that code, updating my @types/node-app-store-connect-api definition every time Apple introduces a new URL you can request. Testing and debugging that is a challenge in its own right.

And even if I did it, the complexity of my library just went from a few hundred lines of glue code to 1,000+ lines of type generation (plus tests for the generated types).

This is in no way worth it for me. As a library developer, adding TypeScript types would make my life harder.

> And even if I did it, the complexity of my library just went from a few hundred lines of glue code to 1,000+ lines of type generation (plus tests for the generated types).

I would say that the increased complexity of your project would accurately reflect the complexity of the underlying API

> As a library developer, adding TypeScript types would make my life harder.

Yes, but it would mean that the various parameters passed to your library would now be type safe, which sounds worth the work

One clear moral of this story is that, as a library developer, I need a lot more documentation and tooling support from the TypeScript team.

That string-parsing thing isn't in TypeScript's documentation at all; it's a random blog post. I'm lucky I found it. TypeScript's site should document how to do this.

Furthermore, it should be easier to debug parsed stringly-typed APIs using the `infer` keyword. Today, I just run the compiler over and over again until it stops throwing errors, and the errors are really not very helpful.

There should be a standard tool to help me test that I used `infer` correctly, ideally helping me by fuzzing the code to see if I allowed something I shouldn't have allowed, or blocked something that I should have allowed, and to test against various versions of TypeScript.

Narrowing types shouldn't be done just by nesting ternary expressions. As the article notes, "It's pretty common in style guides to never nest ternaries. In typescript, that's the only way to narrow types based on other types. It's a mess!"

Lastly, this idea doesn't sit right with me:

> I would say that the increased complexity of your project would accurately reflect the complexity of the underlying API

I designed my library so it doesn't need to incorporate that complexity. Users of my API have to learn the API, but they can learn it from Apple, by reading Apple's documentation, and by inspecting the objects that Apple actually returns (rather than what their OpenAPI specification says they'll return).

Incorporating that complexity into my library will make my library harder to work with, more difficult for others to contribute to my library. As the article says, "Types make it much harder to maintain a js library, and especially difficult to contribute to them."

TypeScript is forcing me to duplicate the API's complexity in my code. Even if you think that "sounds worth the work," I think you have to agree that the work load is much higher than the work I've already done.

> Furthermore, it should be easier to debug parsed stringly-typed APIs using the `infer` keyword. Today, I just run the compiler over and over again until it stops throwing errors, and the errors are really not very helpful.

This paragraph kind of sums up both the OP and this whole HN discussion of it. So I'll throw my comment on here, although I suppose it could go pretty much anywhere.

Anyway, one way to read it all is: This just goes to show that

1) JavaScript sucks;

2) Therefore the whole world of "Web apps" built on it is an unmaintainable buggy nightmare;

3) Trying to graft "strong" (not really) typing on top of it in the shape of TypeScript is just polishing a turd.

It's like somewhere around 1995/2000 the world of computing jumped through a time warp back to 1975, and we've been stuck there, in a world dominated by the new BASIC, ever since.

___

Edit: Typo fix, *"domination" --> "dominated".

> Depending on which URL you request, you'll get different result object back.

This sounds awful to me. Why wouldn't it be separate functions? I absolutely would not want that at all as an end user, I'd find it confusing and frustrating.

Because in order to have separate functions, I'd have to define separate functions for every function that Apple supports, i.e. I'd have to autogenerate the list from Apple's OpenAPI specification.

Furthermore, if Apple introduces a new function, I'd have to release a new version of my library to support it. Today, my library can handle any object Apple's API supports, without upgrading.

As it stands, the API works like this. It's fine.

    const {data: app} = await read('apps/123456')
    const {data: apps} = await read('apps')
    const {data: [firstApp]} = await read('apps?limit=1')

Swagger can generate that sort of thing. I guess I don't know what things your library provides so I don't want to bash it, but having a generic read/get that doesn't provide types doesn't seem like a big improvement over just using a general purpose tool like axios or fetch.

The App Store Connect API requires scoped, time-limited tokens to be generated and has specific filtering, pagination, and rate-limiting mechanisms built into every resource. I haven’t looked at this particular library, but I would expect that it’s quite useful beyond simply making the HTTP requests.

I think it’s great that you publish and maintain this library and nobody can or should tell you to put more work into it. That said a package that did have explicit methods for every endpoint with documentation of what it does and what the parameters are would be awesome for me as a user. The docs will pop up when I write the code and make it easy to explore the different methods from my editor. No need to switch to the apple docs all the time (but probably still sometimes). And again I still think your library can stay as it is. I really don’t think this string parsing magic is the way to go. It can be useful in some simple cases, but specifying a whole API goes to far imho.

Reply on news.ycombinator.com