What do you think about this approach using Typescript and React?

[tawdry dagger]

Hi!

Recently, some co-workers and I have been discussing a use case which involves React and TypeScript.

We are working on an app related to logistics, and in this app, we have an entity called Order. Among many other properties, an order has a property called status. This status property can be one of four different strings: pending, invoiced, created, and closed. These statuses are defined in an Enum on the backend (It doesn't matter, but the backend is written in PHP with Symfony).

This means that the backend will always return one of these four known statuses, not random strings.

Okay, knowing this, on the front-end, with React and TypeScript, I created a type called OrderStatus with the four possible statuses, something like this:

type OrderStatus = 'pending' | 'invoiced' | 'created' | 'closed'

export default OrderStatus

At this point, the discussion starts from the fact that my colleagues are not happy with me re-defining the types on the front-end. Their argument is that if we change a status name on the backend, we'll have to change the status also on the front-end, claiming that this is redundant.

I have to say, that my colleagues have no experience working with TypeScript; they are more focused on the backend, especially in PHP and Symfony.

From my point of view, it is really important to have these things typed because if the possible statuses are already defined on the backend, it means that they are consistent. Knowing what kind of value the backend can return to you could be really useful when performing certain actions based on the type of the status. Just imagine that I have to show or not show a button based on the status type, for example, when the order is pending.

I would like to read your thoughts about this, and if I am right, what argument would you give to my colleagues, because it seems that they are not understanding my point. If I am not right, I would like to know your opinion as well.

Thanks in advance!

[deep wolf]

if this comes from the backend, and it is actually specified as being one of those four strings rather than just any string, then changing one of them is a breaking change. is there some system in place to deal with that? like you can forcibly-update old clients when the backend changes? if not then you have a problem no matter how you type things

[tawdry dagger]

No, we don't have a system in place to deal with that, if we change a status name, for example, a dumb change like replace pending for pendings we'll have to update the places on the backend and the frontend where we use that status.

[deep wolf]

i was talking about what happens when you deploy that change to production. there will be existing clients in the wild without the new code, and they will presumably break in strange and mysterious ways until they force-refresh the page

if that's right, the problem goes deeper than how to keep this union in sync. you can't just make breaking changes like that willy-nilly. you need a phased deployment and/or some way to force clients to update or just some plan in place

i don't know the context though, maybe you don't care that clients become broken when such a change happens

[tawdry dagger]

The app is not in production yet.

Maybe I am misunderstanding you, but I am approaching this argument to keep the union in sync with the backend; nothing about production or customers yet.

[rich idol]

@tawdry dagger What are they suggesting? Just using string in place of OrderStatus?

[tawdry dagger]

Yes, or start using some complex logic, employing numeric codes for every type of status to differentiate each other and perform different actions depending on the numeric code. I don't get this solution that they propose, to be honest.

[rich idol]

If you used numeric codes, you'd still probably still want to have a union

type OrderStatus = 
   | 123 // pending
   | 234 // created
   | 000 // closed

Assuming you're representing their point right, I think you're correct here. Like they said, if the backend changes, the front end code needs to change too and having a specific type makes it much easier to actually find the correct places that need to change.

Unless you can somehow generate the frontend types from the backend code, you'll have to write types on the front end, even if they're "redundant"

[tawdry dagger]

I totally agree with you. I don't get the point of not typing this, knowing that the status will always be a controlled string because it is defined in an enum on the backend. There's nothing about random strings. In that case, of course, I would define the status as a string.

Thanks for your opinion. I will try to recollect arguments and documentation, or posts talking about this. That is my only way of convincing them. It will be painful to deal with that module without typing this, knowing that there is a lot of business logic on the front.