Deck.gl: Add Flow type definitions

[NameFILIP]

Are there any plans for doing this? It would be useful to developers to catch typos and guarantee they are using the library correctly.

[ibgreen]

@NameFILIP We don't use flow in the deck.gl source code, because we don't want to tie the source code to a specific technology (e.g. flow vs typescript...), however we are very interested in offering an "independent" set of flow type definitions to enable type checking when importing deck.gl in applications that use flow.

It has been talked about a number of times but no one has contributed anything so far.

We do have a prop type system so it might be possible to autogenerate certain type definitions, there is some initial code if someone is interested.

[NameFILIP]

by choosing either flow or typescript you'll be safer than without them, so not tying to a specific technology is more of a disadvantage rather than a benefit. You can always strip the types when you publish it so that consumers are not tied to the specific technology.

Alternatively, you can provide definitions for only the public API which will give type safety to consumers, but will not help you a lot.

[lxe]

You/me (or any third-party) can add them to

• For Flow: https://github.com/flow-typed/flow-typed and
• For TypeScript: https://github.com/DefinitelyTyped/DefinitelyTyped

[vicapow]

Adding a Flow types, either by adding them to the source code, or publishing them as a seperate libdef, would definitely help prevent bugs for projects we have internally when updating the dep in our monorepo.

[cain-wang]

Or probably we can wait for a little bit and then everybody will move to TypeScript, then we only need to provide one type def :)

https://jaxenter.com/yarn-v2-roadmap-154962.html

[NameFILIP]

don't like the waiting part, but I'd love if the world abandoned any of these and only had one JS type system

[vicapow]

I'm not sure waiting to rewrite all of our code is really practical solution here.

[ibgreen]

by choosing either flow or typescript you'll be safer than without them

I have tried to explain my position on this topic to "flow and typescript proponents" a couple of times with rather mixed success, but I'll give it a try:

As much as I would love types, a type system is a non-starter because of how I view open source code. I do not see our open source code as just "an API and an npm module" that we publish for people to reuse (which we can then write in any JS dialect/language we choose, as long as we babel-transpile it to ES5/ES6/... before we publish).

I see what we offer as MIT licensed archive of very high quality, standard ES6+ source code that people can cut and paste pieces from and reuse in their own projects.

With this view, each non-standard syntax we adopt dramatically reduces the number of people who can just copy and paste our code into their projects.

I personally use source code from other MIT projects in this way, and think it is one of the great benefits of the open source model/community. However I always "move on" when I find the code I am interested in was written in some non-standard format, whether it be coffeescript, flow etc.

I'd love if the world abandoned any of these and only had one JS type system

Amen.

Adding types would seem like a logical next step in the evolution of the JS standard?

[NameFILIP]

What are the use-cases for people to cut and paste pieces of deck.gl code?

Types can help you to have "very high quality" code (15% reduction of bugs https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-quantifying-detectable-bugs-in-javascript/).

And if you see a lot of value in having standard ES6+ source code you can get it in one step like:

babel --plugins @babel/plugin-transform-flow-strip-types **/*.js

which you can have in the package.json scripts.

[ibgreen]

Since this has become a discussion around adopting flow inside deck.gl will close this issue - we'll open a new issue focused on adding flow type definitions.

I'll add a final response, happy to discuss more in person if desired.

[ericsoco]

@ibgreen 's made his case pretty clearly IMO.

That said, I'll add one more perspective:

Adding Flow types to an existing codebase is resource-intensive and onerous and does not guarantee type safety. Partial static type coverage can be dangerous in its own right, allowing authors to make assumptions about safety that are ensured by the type checker that can be controverted at runtime.

You can list me generally in the "Flow proponents" category, but having gone far down the path of adding Flow types to an existing codebase, I can say with certainty that it's not an unqualified win.

[ibgreen]

A change could happen if the folks actually contributing to deck.gl really want to use types, and then the choice of which type system to use depends on how dominant one of these solutions becomes, and what the team wants e.g. typescript vs flow etc.

[ibgreen]

What are the use-cases for people to cut and paste pieces of deck.gl code?

Good question! There is a lot of potentially reusable code in deck, including:

• geospatial coordinate projection classes that use advanced optimization techniques
• event handling controllers
• shader modules
• code that sets up data for GPU
• management of attribute transitions
• a prop type system
• a component lifecycle management system
• a webgl font rendering system
• many code examples
• layer subclass examples
  etc...

In fact we have built up entire frameworks (e.g. loaders.gl and math.gl) in short time by cutting, pasting code and repurposing code that was almost but not quite reusable from other places. We'd love it if others could benefit in the same from our code.

[ibgreen]

@NameFILIP #2647