Tricks I wish I knew when I learned TypeScript • Hacker News Board

Re: Tricks I wish I knew when I learned TypeScript

#261

Post by goto11 » Wed, Oct 13, 2021, 7:16 AM UTC

underdeserver wrote: post #162

ebingdom wrote: post #144

Earlier quoted context omitted.

> Barely typed languages like C made rigorously typed languages like C++ and Java seem appealing. The boilerplatiness of those languages made duck typing seem appealing. Eh, I consider Java to be barely typed too. If you have a variable of type Foo, the type system doesn't even guarantee that you have a Foo in there (it might be null). The whole point of a type system, in my mind, is to guarantee that I have that Foo…

I know dozens of people who tried understanding Promises and all of them succeeded. I know dozens of people who tried to understand monads (including myself) and maybe 3 of them succeeded (I do not consider myself one of them).

The problem with monads is they are only really practical in a language with built-in syntactic sugar to cover the boilerplate. In any other language you will surely go "whats the point?" because using monads will invariably turn simple code into a convoluted mess for no benefit. Promises on the other hand will seem immediately useful if you have tried writing async code in an ad-hoc manner. Promises solve a problem.

Mathematicians and Haskelites tend to explain things by giving their definition. (Imaging a Haskelite explaining how to write "hello world" in C: First you need a "main" function. A function is a process or a relation that associates each element x of a set X, the domain of the function, to a single element y of another set Y (possibly the same set), the codomain of the function. etc etc )

But most other programmers prefer to understand things by understanding the problem they solve. It is quite obvious what problems Promises solve, but in the context of JavaScript, monads does not solve any real world problem. That makes them hard to grasp for a programmer, even though the concept is simple.

Monads are a particular pattern for method chaining or function composition.

Here is an example of some JavaScript code which use regular method chaining:

    [1,2,3].map(a => a + 1).filter(b => b != 3)

This code results in the array [2,4].

Similar code following the monad pattern would look like this:

    [1,2,3].flatMap(a => [a + 1]).flatMap(b => b != 3 ? [b] : [])

And the result is the same. But obviously the monadic version is more convoluted and harder to read. But if there was some syntactic sugar which covered the boilerplate, then the monadic version might be bearable!

The "power" of the monadic pattern is that the operations can be chained or nested in a more flexible way. For example here the operations are nested, but the result is the same:

   [1,2,3].flatMap(a => [a + 1].flatMap(b => b != 3 ? [b] : []))

This does have some nice properties, since operations can be chained or nested together to composites which have the same type as a single operation. The question is if the benefit outweighs the cost in code complexity.

The monad pattern is purely concerned about how operations are chained together structurally, it is not about what they does or what types are involved. In this example the type is Array, but it could be any parameterized type.

Monads can be used anywhere a sequence of operations is stringed together. (But that doesn't mean you would want to.)

Re: Tricks I wish I knew when I learned TypeScript

#262

Post by scotty79 » Wed, Oct 13, 2021, 7:35 AM UTC

ofrzeta wrote: post #253

skywal_l wrote: post #43

Utility Types[0] will help you get to the next level on Typescript. It's important to know them and know how and when to use them. [0] https://www.typescriptlang.org/docs/handbook/utility-types.h...

I really don't get the point of operations on types such as 'type TodoInfo = Omit '. Is this a real use case? Why not just literally write down the properties? Surely easier to read and in the end maybe even easier to maintain.

It depends on what your anticipation of the future evolution of TodoInfo type is.

If you think it will have more special fields like completed and createdAt that you don't want to pass on in most contexts, then it's better to list the fields that you want to pass on.

But if you expect it to not have more of those and rather get (or loose) more fields that you want to pass on, then it's better to list the ones that you want to omit.

Another trade-off might be that when the new field is added and you'll forget to update the other pieces of code, will it do less harm to pass the field you intended to omit, or to omit the field you intended to pass. Or which error will be easier for you to discover in your use case.

Re: Tricks I wish I knew when I learned TypeScript

#263

Post by toxik » Wed, Oct 13, 2021, 10:01 AM UTC

Shorn wrote: post #248

toxik wrote: post #180

Earlier quoted context omitted.

A monad is just a monoid in the category of endofunctors, what's the problem?

HN may not be the place for these kind of comments - but I will never not up-vote this specific comment.

I think they work well as long as they're reasonably specific, reposting the famous HN Dropbox comment also works pretty well on HN. Other redditisms don't fare so well, and for that I'm thankful.

Re: Tricks I wish I knew when I learned TypeScript

#264

Post by 0x6c6f6c » Wed, Oct 13, 2021, 11:17 AM UTC

skywal_l wrote: post #101

yulaow wrote: post #90

Earlier quoted context omitted.

This seems extremely hard to read for me, I would have an hard time trying to understand what it does if I found it in any source code

type Ensure I define a type called Ensure This type takes two type parameters, one called T and the other K which will consist of Keys belonging to the type T (in our case, "foo", "bar" or "baz"). = T & This new type (called Ensure) will be equal to the union of two types: One will be T and the other will be: { [U in keyof Pick ] A new type which keys will be picked among the key listed in K -? To which we will remov…

Only one small terminology issue: & is an intersection of types, a union is |. So Ensure is an intersection of T and the latter type.

Wouldn't Required suffice here as well for this as opposed to removing the optional qualifier?

Re: Tricks I wish I knew when I learned TypeScript

#265

Post by kbenson » Wed, Oct 13, 2021, 4:20 PM UTC

kilburn wrote: post #241

Androider wrote: post #237

Earlier quoted context omitted.

The beginner programmer copies the property definition. The advanced programmer simply writes "type Ensure = T & { [U in keyof Pick ]-?: T[U] };", thus removing the need to copy the property. The master programmer copies the property definition.

Do you have some argument? Without arguments, your comment has as much substance as me replying: The beginner programmer copy/pastes the code. The advanced programmer writes a function, thus removing the need to maintain copies of the code. The master programmer copy/pastes the code. It is not like "Ensure" would be a single-use thing. "Ensure" here is a utility type definition, which is what a "function in the world…

I think they're going for a "The Codeless Code"[1] type of koan. The idea is to express through something that may seem slightly illogical or counterintuitive an insight.

> Without arguments, your comment has as much substance as me replying:

Yes, what you substituted is equivalent, and they likely could have written that to the exact same effect.

> It is not like "Ensure" would be a single-use thing. "Ensure" here is a utility type definition, which is what a "function in the world of types" would be.

There's a few ways to interpret the stanza. The way I interpreted it is that the beginner uses a library to provide the definitions, the advanced programmer just writes their own definitions inline as needed, and the master programmer uses a library for the definitions they need (whether written by themself or someone else).

In that respect, I think you're both in agreement.

For what it's worth, I think comments like these are generally beneficial, if maybe I prefer at least a line of context. That they can be interpreted differently and may require a bit of thought to map onto the current context can sometimes allow people to view their beliefs from a slight remove where more introspection is possible, or spur interesting tangents to explore. Both of those are generally beneficial in a forum like this, IMO.

1: http://thecodelesscode.com/contents

Re: Tricks I wish I knew when I learned TypeScript

#266

Post by irrational » Wed, Oct 13, 2021, 4:22 PM UTC

mbrodersen wrote: post #254

irrational wrote: post #127

Does Typescript get better? I've been forced to use it for my most recent project, but haven't been given any time to read through the documentation. I've found that I'm spending about 99.9999% of my development time trying to figure out how to get my IDE to not show that their are typescript problem. At this point I hate typescript with the burning fury of a trillion suns. I wonder if this is everyone else's experie…

So you didn’t read the (very easy to read) documentation and then complain that you can’t figure out how to use it? And then you wonder why people are downvoting you?

I haven't been given time to read the documentation. I was told TS is simple enough that I can just figure it out on the fly.

Re: Tricks I wish I knew when I learned TypeScript

#267

Post by nsonha » Wed, Oct 13, 2021, 9:16 PM UTC

skywal_l wrote: post #43

Utility Types[0] will help you get to the next level on Typescript. It's important to know them and know how and when to use them. [0] https://www.typescriptlang.org/docs/handbook/utility-types.h...

the only complain have with these is that there is no namespace or anything that allows me to discover them. You have to follow all the release notes or check lib.d.ts. In comparison, flowtype prefixes them with $, so when I type "$", I get the suggestion.

Re: Tricks I wish I knew when I learned TypeScript

#268

Post by nsonha » Wed, Oct 13, 2021, 9:18 PM UTC

ofrzeta wrote: post #253

skywal_l wrote: post #43

Utility Types[0] will help you get to the next level on Typescript. It's important to know them and know how and when to use them. [0] https://www.typescriptlang.org/docs/handbook/utility-types.h...

I really don't get the point of operations on types such as 'type TodoInfo = Omit '. Is this a real use case? Why not just literally write down the properties? Surely easier to read and in the end maybe even easier to maintain.

A higher order react component that consumes those props and swallows them before passing down to the target.

Re: Tricks I wish I knew when I learned TypeScript

#269

Post by mbrodersen » Wed, Oct 13, 2021, 10:06 PM UTC

irrational wrote: post #266

mbrodersen wrote: post #254

Earlier quoted context omitted.

So you didn’t read the (very easy to read) documentation and then complain that you can’t figure out how to use it? And then you wonder why people are downvoting you?

I haven't been given time to read the documentation. I was told TS is simple enough that I can just figure it out on the fly.

Well you have been told wrong. However it only takes about an hour to read the type docs. So take the time why not? Isn’t that better than being frustrated?

Re: Tricks I wish I knew when I learned TypeScript

#270

Post by Attained » Wed, Oct 13, 2021, 10:41 PM UTC

ofrzeta wrote: post #253

skywal_l wrote: post #43

Utility Types[0] will help you get to the next level on Typescript. It's important to know them and know how and when to use them. [0] https://www.typescriptlang.org/docs/handbook/utility-types.h...

I really don't get the point of operations on types such as 'type TodoInfo = Omit '. Is this a real use case? Why not just literally write down the properties? Surely easier to read and in the end maybe even easier to maintain.

Renaming attributes propogates through these types. It makes refactoring better.