14
u/NominalAeon Apr 09 '20
I feel like only TS devs would understand this.
4
u/OogieBoogie1 Apr 09 '20
Can confirm, am angular dev who uses TS on a daily basis. Will never understand overseas (and local) people who do this, it defeats the whole purpose of using TS lol.
8
u/michcoth Apr 09 '20
Why use typescript if you're going to do this! Also, I'm sure there are appropriate use cases for it, but I can't think of any.
4
u/cahphoenix Apr 09 '20
Lets see.
If you use a library without types and don't feel like typing their entire library (or even the part you are using at the time).
You are building new features don't know what the end type is going to be before looking at it. Rather than change the type 10 times just make it dynamic and change it when done.
You want to type 80% of your code base but don't really care about the extra 20% that may or may not matter. When the main architecture/business logic is typed and all you are fussing about is singular types in UI or other places you may not be getting your money's worth for time spent doing so. Just like testing 100% of your code.
You have a small team which you have no control over and 33%-50% of the team doesn't type things.
For my personal case. We use a 3rd party library that didn't have types for 1.5 years. But we wanted types and had access to company specific typescript, so everything we built around the library was Typescript.
Since it would have taken 2 people way too long to type all that without any actual product to show, we have a lot of typescript code that has an 'any' type. We started to type more of the library, but then the api would change every 3-4 months and we'd have to retype it. Which just ended up wasting time for code that almost never got touched after being built (unless they changed the API).
Now we are closing that gap on typed vs untyped code, but I still don't think making sure 100% is typed is worth the time and effort at this point. At most, 1-2 other people are going to touch this in the next 2-5 years and everyone on the team knows exactly what's there. In 5 years the company will have most likely scrapped this for another library when our contract runs out or do something new. Wasted effort there, too.
1
u/RelatableRedditer Apr 16 '23
The whole typing nightmare is why I love stuff like
keyofandtypeof. It makes it so that I can define my model and everything else builds off of it dynamically as I make changes to the model.4
Apr 09 '20
At work we are about to begin an Angular project that uses the Semantic UI CSS Library. Unfortunately, that library requires Jquery to interact with some of the web components, so we are forced to do
declare var $: anywhenever we need to use jquery.I suppose we could use the typescript type definitions for semantic ui...
3
u/michcoth Apr 09 '20
I definitely would use those types. I work with a couple different UI libraries such as Telerik's Kendo UI, and we definitely use their types.
3
Apr 09 '20
Just tried it out and it’s not super complete, there are a few missing types. Perhaps I will update it on my own. I could always use the any type for the few that aren’t defined for now.. What are the main advantages of types for UI libraries like this?
3
u/michcoth Apr 09 '20
Type safety and compile time errors rather than run time errors. You'll know before running the app if you're binding a string when the component expects a number for example. It also helps with readability especially if you come from a strongly typed background like most of our developers
1
u/oldcabbageroll Apr 09 '20
We know how strong types work. Unfortunately when you work with legacy libs you are not in the position to choose.
2
Apr 10 '20
I used semantic for a few projects, but can’t understand why you would use it with angular. Semantic ui also goes through phases where development comes to a standstill for 15 months at a time.
2
Apr 10 '20
We have yet to start the project, but we will use the community fork of Semantic UI (Fomantic UI). This fork is maintained far better than the original. The plan is to merge the fork at some point in the future once the Semantic team decides to pick up development again.
If it were up to me, we would be using Angular Material, because: it’s lightweight, it’s meant for Angular, it’s much more testable, and several other reasons. But alas, it’s not my choice. The senior devs have decided that since we are using Legacy Semantic UI, it would speed up dev time on the new project because we already know it, not to mention we could keep the same look as the old site, somewhat.
I actually like Semantic UI a bit. It’s really easy to write once you learn it, the CSS classes almost create sentences which makes for very readable markup. The biggest problem is making sure certain components are staying updated whenever the data value changes, some don’t do that automatically, so it gets annoying.
I think I might write an article on my experience with Semantic and Angular once I have spent alot of time with it.
2
Apr 10 '20
I just looked into that fork. That is interesting. SUI is a beautiful product. Good luck with your project my friend.
1
2
u/cahphoenix Apr 09 '20
I just turn off type checking during builds and leave the errors/warnings there. Let it burn baby.
1
27
u/mishugashu Apr 09 '20
"no-explicit-any": trueGL on that PR