search

HumanSignal / label-studio-frontend

Data labeling react app that is backend agnostic and can be embedded into your applications ā€” distributed as an NPM package
https://labelstud.io/
Apache License 2.0
414 stars 315 forks source link

Typescript support #714

Open richardo2016 opened 2 years ago

richardo2016 commented 2 years ago

Hi : )

I am one frontend engineer, I used to build web app such label-studio-frontend WITH TypeScript/Javascript. I found label-studio is a grateful & useful annotation tool for my friend who works on AI, he/she needs to label/annotate data to prepare data for his/her training model.

Like some projects I seeked or wrote for them, the frontend of label-studio is not driven by TypeScript, so its customer could not benefit from its Type system. if you install @heartexlabs/label-studio and import it to your existed project, no any Type Hints for frontend engineer.

image

Maybe, I think, we should introduce Typescript into label-studio now, reasons below:

  1. In 2022, more and more frontend projects are built with Typescript, most frontend engineers have been used to it and want explicit type hints when they import one new npm package to their project --- even though their own project isn't driven by Typescript, they can still benifit from IDE's TS Server support (e.g. VS Code)

  2. On the early stage of label-studio, maybe some full-stack engineers can develop both backend and frontend of label-studio. But as your project/product label-studio become biggier and more complex, and you want to sell the commercial version to your customer, they maybe need to tell their frontend engineer: "embed label-studio into our products". But, We all know the fact: most frontend engineers don't know how AI engineer works, what AI engineer needs. So the frontend engineer needs to read your document, to learn the domaintic knowledge and the conception in label-studio first, then he/she could embed label-studio gratefully.

But, if label-studio provides type support in npm package, most frontend engineers could benifit from it: they maybe know less about annotation/label, but the property exported const types, function signature would help them know what capability label-studio provides, with the example in documentation, they would embed it into an existed project faster.

nicholasrq commented 1 year ago

@richardo2016 thank you for the suggestions! yes, totally, we're currently considering different options transitioning LSF to TypeScript or at least providing a decent .d.ts declarations. This is something we definitely want to deliver. Unfortunately, I can't currently give you any estimations on when it will happen as the codebase is pretty massive, and any approach we take on it will require time to implement.

epeters3 commented 1 year ago

This is the process our team used to adopt Typescript, and it worked well:

  1. Set up the scaffolding and build process (e.g. create a tsconfig.json file). You guys have already done this :heavy_check_mark:
  2. Add types for the main entrypoint. This would be the LabelStudio class including all its arguments, and will add the most initial value to those consuming this package.
  3. Follow the "if you see it, type it" principle. .ts and .js files can be mixed in a project, so you don't have to migrate to Typescript all at once. Instead, during normal development activity, you can ask anyone who makes an edit to a .js file to also convert it to a .ts file and add types to it.
erinmikailstaples commented 1 year ago

Hey all!

Thank you, @epeters3 for adding your tips to this! It's super appreciated!

I know this is a conversation that the community has been enthusiastic about and I've heard it from the community lens as well ā€” so just adding the Community Label and getting myself set up for alerts to keep in touch with updates. :)

Definitely appreciate the input and appreciate the transparency from @nicholasrq. šŸ˜„

richardo2016 commented 1 year ago

@richardo2016 thank you for the suggestions! yes, totally, we're currently considering different options transitioning LSF to TypeScript or at least providing a decent .d.ts declarations. This is something we definitely want to deliver. Unfortunately, I can't currently give you any estimations on when it will happen as the codebase is pretty massive, and any approach we take on it will require time to implement.

I'm glad your team is considering these suggestions! In addition to my gratitude, please allow me to offer some of my own insights.

When you mentioned "considering different options transitioning LSF to TypeScript," I believe this indicates that your team "will take some measures to provide types with minimal changes to the existing code." In my opinion, the best way to achieve this is actually to rewrite the existing JS/JSX files in TypeScript. The remaining issues can be solved using TypeScript's complete toolchain.

I do not recommend to "providing a decent .d.ts declarations." I have seen many JS frameworks and libraries do this, and it can work for smaller libraries with stable external interfaces. However, for a project like LFS, which constantly changes component behavior and external interfaces as the business evolves, writing a separate *.d.ts file in addition to writing JS code is a heavy burden. Moreover, once a team abandons synchronizing the interface definitions of JS code with *.d.ts for the sake of iteration speed, it actually creates bigger problems for the users: the official generated types/interfaces are incorrect.

Travis1282 commented 1 year ago

I do not recommend to "providing a decent .d.ts declarations." I have seen many JS frameworks and libraries do this, and it can work for smaller libraries with stable external interfaces. However, for a project like LFS, which constantly changes component behavior and external interfaces as the business evolves, writing a separate *.d.ts file in addition to writing JS code is a heavy burden. Moreover, once a team abandons synchronizing the interface definitions of JS code with *.d.ts for the sake of iteration speed, it actually creates bigger problems for the users: the official generated types/interfaces are incorrect.

I agree with this approach, and although new components are written in typescript the main entry point for lsf should be prioritized to include definitions that can help both dev's looking to integrate as well as those working to transition the existing code base. It feels like an achievable and bite size first step that will pay big dividends.

nicholasrq what would it take to get this prioritized?

jheyming commented 1 year ago

When might this be prioritized?