loading...

re: The Trouble with TypeScript VIEW POST

TOP OF THREAD FULL DISCUSSION
re: If it can be done in Javascript it can be done in Typescript. I'd have to disagree with this statement. There's a lot of very dynamic JS behavi...
 

Yes those definitions are very complex; too complex, and most likely an indication of a bad design.

I've looked into redux before and rejected the concept of separation of state concerns to other components.

The MVVM pattern kept state in the view model and there were no state issues in past 20 years. State concerns do not need to be farmed out.

My point had nothing to do with whether Redux is a tool you should use or not.

I'm simply saying that connect is a highly dynamic JS API that was designed before TS became popular. It accepts multiple arguments, all of which are optional, the first two arguments have multiple possible overload forms, and the result is a React "higher order component" that passes those derived props to your own component. It's a very JS-centric API. Thus, trying to define typedefs for that dynamic behavior becomes harder.

In contrast, our new React-Redux hooks API is two functions:

const dispatch = useDispatch();

const todo = useSelector( (state: RootState) => state.todos[props.id]);

We didn't specifically design them that way just to work better with TypeScript, but the ability to type them easily was a factor in our consideration.

So, as I said: there is some JS behavior that is extremely hard or impossible to type correctly in TS. Therefore, TS usage pushes you to design APIs that are easier to type.

I have seen C# apis, where one endpoint served many different things. All were later ripped out as the 'SRP' Principal was a better pattern.

I'm simply saying that connect is a highly dynamic JS API that was designed before TS became popular

I was only noticing the 'less than optimal' design of allowing an interface to accept dynamic parms. Of course it's only an opinion.

code of conduct - report abuse