DEV Community

Discussion on: The Trouble with TypeScript

Collapse
 
jwp profile image
John Peters

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.

Thread Thread
 
markerikson profile image
Mark Erikson

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.

Thread Thread
 
jwp profile image
John Peters

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.