Suppose we have a large to-do task manager app with many features. Say we have an entity, which is the task, and it has certain fields like: title, description, deadline, sub-tasks, dependencies, etc. This entity is used in many parts of our codebase.
Suppose we decided to modify this entity, either by modifying, removing, or adding a field. We may have to change most if not all of the code that deals with this entity. How can we do this in a way that protects us from errors and makes maintenance easy?
Bear in mind, this is just an example. The entity may be something more low-key, such as a logged user event in analytics, or a backend API endpoint being used in the frontend, etc.
Potential Solutions
Searching
One way people do this already is by just searching the entity across the codebase. This is not scalable, and not always accurate. You may get a lot of false positives, and some parts of the code may use the entity without using it by name directly.
Importing
Defining the entity in one central place, and importing it everywhere it is used. This will create an error if a deleted field remains in use, but it will not help us when, say, adding a new field and making sure it is used properly everywhere the entity is being used
so what can be done to solve this? plus points if the approach is compatible with Functional Programming
Automated Tests and CICD
Tests can discover these types of issues with high accuracy and precision. The downside is… Well tests have to be written. This requires developers to be proactive, and writing and maintaining tests is non-trivial and needs expensive developer time. It is also quite easy and common to write bad tests that give false positives.
Typescript, but that’s not the issue. You probably have to leverage types in a specific way to get all the protections I am talking about. For example, I want it such that if a new field is added to a type, every user of the type must explicitly either use it or explicitly declare that it won’t. From my experience with type systems, you typically aren’t required to explicitly declare that you won’t use a field in a dictionary / record type.
Ok, TIL there’s a thing called Required, but otherwise, one way to do this is to rename the other part/field/key(s), so that old code reveals itself in much the same way as using a deleted field (because it does, actually)
Another way is explicitly have a separate type for records with/without the feature. (if one is a strict subset, you can have a downgrade/slice method on the more capable class.
Lastly, I would say that you need static typing, testing, both. People from static-land get vertigo without types, and it does give good night sleep, but it’s no substitute for testing. Testing can be a substitute for static typing in combination with coverage requirements, but at that point you’re doing so much more work that the static typing straight jacket seems pretty chill.
What? How does someone declare that they won’t use a type? What does that even mean?
Do you have an example use case that you’re trying to solve? What additional type are you adding that would break existing users usage? If that’s the case, maybe use an entirely different type, or change the class name or something
I gave an example use case in the main post, but I’ll summarize it again here:
Suppose we have a to-do task manager. A task is an important entity that will be used in many parts of our codebase.
Suppose we add a new field to this task entity. For example, let’s say we now added a priority field in our task that previously didn’t exist, so users can define if a task is high priority.
The problem: this task entity is being used in many parts or our codebase. How do we make sure that every one of those parts that needs to use the new field does use it? How do we make sure we don’t miss any?
I hope this makes sense. If it doesn’t, feel free to ask any questions.
Have you considered the
Required<T>generic?https://www.typescriptlang.org/docs/handbook/utility-types.html#requiredtype
Thanks for the tip! I think that is indeed what I need. Thank you :)
Oh are you talking about creating the object? Yeah I think you might get better answers in a TS thread, because that question and the response here makes no sense in most statically typed languages.
I am still confused about what OP is looking for. Even in typescript, if a new field is added and not used in other places, compilation will fail. Unless OP explicitly marks the field as optional.
There’s also the possibility that the codebase is littered with the “any” keyword (I’m not saying OP is doing it but I’ve definitely seen plenty of codebases that do this). If someone says they’re using typescript but their code is full of “any” keywords, they’re not using typescript. They’re just using plain JavaScript at that point.
That’s if the field is added but never used. If it is used in some parts of the codebase, but not used / handled in others, compilation will pass. I would prefer that it doesn’t. I would prefer that if such a change were to occur, that every part of the codebase that uses that entity is explicitly addressed by the change made.
Again, if there’s anything you don’t understand, feel free to ask me directly. I do not get notifications when you reply to a comment that isn’t mine.
It still doesn’t make sense. Obviously your whole explanation hinges very heavily on what exactly you mean when you say “not used/handled” . Depending on your specific use case this could mean anything. As with any code related question, there’s only so much that people who haven’t seen your code can do to help. I think the easiest way to avoid this confusion is to just show some code so we are all on the same page about what the issue is.
On thinking about this a bit more, I feel like you may be expecting the system to handle situations where your business requirement needs the new field to be used now, but used to work without this field before. Based on the example you provided, I am imagining something like a getTasksForUser functionality which previously might have just been filtering on userId but if the business now says that this functionality should now return tasks sorted by priority, you expect the system to somehow know the business requirement and force the developer to use this new priority field ?
If that’s what you’re hoping for, the problem is harder to solve although not impossible. Assuming the example as above , you could maybe just inject the priority field at the data access layer . Another way would be to make the modified entity private and expose a facade with helper functions that are exposed. Now when code that previously used to rely on the entity inevitably breaks , you can replace those usages with usage specific functions exposed from the facade and since the entity is now accessible only from the facade, you can easily update all usages within the facade and make sure no one can miss passing the priority field since the entity is private to the facade and all functions in the facade are known to use the new field.
If there’s anything that doesn’t make sense in my question, feel free to ask any questions or clarifications on any part of it.
Yeah, in most statically-typed languages this is simply the default behavior unless you specifically declare a field as optional.
A simple but hackish solution is to version your types. New field? Foo becomes Foo2! Now nothing builds and you’re sure you’ll have to go over every usage of the type.
Add a second commit to revert to Foo, and there you go. Of course you’d need two reviews but the second one is trivial