You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be nice to clean up the code a bit and add type bindings.
The plan is to use Flow types for the code itself. We will also export types for other flow users to use.
We will not write the code in TypeScript, but we may consider making TypeScript bindings available.
The question about TypeScript at the moment is primarily where to put them.
The official documentation recommends that packages not written in TypeScript publish types with DefinitelyTyped.
However I find that a lot of widely used libraries not written in .ts still distribute .flow and typescript definitions alongside their code.
However given that currently both @types/fb and @types/facebook-js-sdk both exist and both are for Facebook's client-side JavaScript SDK. It might be simpler to
Except types are going to get messy should we implement #152 and effectively wrap the types of the entire SDK that Facebook provides.
The goal is to use Flow internally support both Flow and TypeScript consumers. So #63 and #46 which only suggest TypeScript definitions and are out of date are obsolete discussions.
The text was updated successfully, but these errors were encountered:
It would be nice to clean up the code a bit and add type bindings.
The plan is to use Flow types for the code itself. We will also export types for other flow users to use.
We will not write the code in TypeScript, but we may consider making TypeScript bindings available.
The question about TypeScript at the moment is primarily where to put them.
The official documentation recommends that packages not written in TypeScript publish types with DefinitelyTyped.
However I find that a lot of widely used libraries not written in .ts still distribute .flow and typescript definitions alongside their code.
However given that currently both @types/fb and @types/facebook-js-sdk both exist and both are for Facebook's client-side JavaScript SDK. It might be simpler to
Except types are going to get messy should we implement #152 and effectively wrap the types of the entire SDK that Facebook provides.
The goal is to use Flow internally support both Flow and TypeScript consumers. So #63 and #46 which only suggest TypeScript definitions and are out of date are obsolete discussions.
The text was updated successfully, but these errors were encountered: