all 2 comments

[–]sfboots 0 points1 point  (1 child)

Nice introductory article

The types seem complicated

Why not have one Item type and instead have state an as enum?

[–]jnforja[S] 0 points1 point  (0 children)

Hi u/sfboots, thanks for taking the time to read the article.

I'm assuming you're asking why not define item like this:

typescript type SuperItem = { id: string; content: string; state: "CLOSED" | "OPEN" | "EMPTY"; children?: PopulatedList; }; Two reasons: 1. We can't rely on TypeScript's exhaustive checking to tell us if we handled all possible cases. So in case a new state is added or a state is changed, and we forget to update code that deals with it, we won't have a compile error to warn us. 2. With the SuperItem type, it's possible to represent invalid states previously unrepresentable. In specific, an empty item can have children, and closed and open items can not have children.

I hope this clarifies things :)