search

fomantic / Fomantic-UI

Fomantic-UI is the official community fork of Semantic-UI
https://fomantic-ui.com
MIT License
3.52k stars 330 forks source link

Use Typescript #456

Open 28Smiles opened 5 years ago

28Smiles commented 5 years ago

Feature Request

Description

Since with v3 the Formantic-UI is going under heavy development and a lot of the JS is rewritten, isn't it a good point of time to write the modules directly in Typescript. This would ensure a slim Typescript integration (#396 ) and probably would also eliminate some Bugs.

y0hami commented 5 years ago

@28Smiles TS is something I want to look into but it could hold back the development since all the members of the core team have no experience with TS (since the last time we discussed it) which would mean we would all need to learn it. That being said I do understand the benefits so this will definitely be a topic of discussing again when it comes to the time to make the decision.

lostfields commented 5 years ago

You can use JavaScript in Typescript, but not the other way around - so it shouldn't be any issue at all if you are not experienced with Typescript. You could make it allow JavaScript as well, and implicit accept type "any" to make the transformation easy.

y0hami commented 5 years ago

@lostfields I have been doing a lot of typescript recently and feel fairly confident with it now and I know @ColinFrick uses it so I don't think that will be the problem going forward anymore. The decision on whether we use TS or not will still depend on whether we are writing the JS our self or using stardust (as discussed here)

YamiOdymel commented 5 years ago

I've tried to write the modules with TypeScript few weeks ago and I had lots of the issue with DOM.

TypeScript suits for the data-only things (Node.js backend for example), but with DOM elements? Not really.

Since there are bunch of the different HTML element types (for example: HTMLTableElement, HTMLTableSectionElement, HTMLTableCaptionElement, HTMLTableCellElement), it's impossible to done the module with TypeScript because it's hard to specify the types of the elements.

If you are smart enough, you might know that you could use HTMLElement interface as a generic type instead of specifying their real types, but and then you lose the methods of each different type of the elements because they are now a HTMLElement.

Also, TypeScript lacks some types in its definitions if you are interacting with the file input.

50553587_1985212471775137_8991193277428400128_o

bjmiller commented 5 years ago

Food for thought. https://medium.com/javascript-scene/the-typescript-tax-132ff4cb175b

douglasg14b commented 5 years ago

I'm an avid TypeScript user for most of my applications, but I would have to agree with @YamiOdymel that it seem like a poor choice for DOM manipulation.

I think focusing more on solid development practices and sticking to a style and architectural guide will do much more for the codebase than switching to TypeScript will.

y0hami commented 5 years ago

I have been thinking a lot about v3 over the past week ready to start planning 👀 and the way I reckon we will build it wouldn't make the DOM types a problem. It's quite complex and is not easy to explain in a few sentences but I do understand your concerns and I do somewhat agree with what your saying. Also what your saying @douglasg14b about the development practices etc I have thought a lot about how we will build v3 and I think the way we will do it will produce the best codebase for the project whether we do or don't use TS.

Hopefully this makes sense, if it doesn't just let me know 😜

thiscantbeserious commented 5 years ago

Let me add that we were at a similiar road-sign previously and we also decided against it - instead moved to use a customized JSHint and SASS-Linter in the build process, that will simply fail the full build if there's an issue (configurated however we wanted - like forbidding !important).

That way you'll have the advantages without going all the way of putting a statically typed language ontop of a dynamic language. With the watcher we just let the build continue and output the error with Plumber applied (also using Gulp).

SkyLeite commented 4 years ago

I've tried to write the modules with TypeScript few weeks ago and I had lots of the issue with DOM.

TypeScript suits for the data-only things (Node.js backend for example), but with DOM elements? Not really.

Since there are bunch of the different HTML element types (for example: HTMLTableElement, HTMLTableSectionElement, HTMLTableCaptionElement, HTMLTableCellElement), it's impossible to done the module with TypeScript because it's hard to specify the types of the elements.

If you are smart enough, you might know that you could use HTMLElement interface as a generic type instead of specifying their real types, but and then you lose the methods of each different type of the elements because they are now a HTMLElement.

Also, TypeScript lacks some types in its definitions if you are interacting with the file input.

50553587_1985212471775137_8991193277428400128_o

This is far from the truth. React has had official Typescript typings that work in 99.9% of the cases just fine, and has been used in production for just as long. What's wrong with having multiple HTMLElement types? You don't really elaborate on why what you said is a problem, you just stated it is.

You also conveniently left out the fact that the screenshot you posted are comments on an issue that offers two perfectly fine workarounds: extending the interface and/or using FileReader.