---
title: To be what you see
date: 2023-05-10
author: zombieJ
---
With daily development, have you thought about a problem. When the range limit is different from the actual value, how should we deal with it? Suppose we have a display component that simply displays your value:
```tsx
interface StrProps {
value: string;
}
function MyStr({ value }: StrProps) {
return
{value}
;
}
;
```
Without a doubt, `Hello World` should be displayed on the page. Next, we add a scope limit:
```tsx
interface StrProps {
value: string;
maxLen?: number;
}
```
What should be displayed if we use a value out of range at this time?
```tsx
```
"Obviously", since you have `maxLen`, you should display `Hello` instead of `Hello World`.
But this intuitive approach is not correct in all cases. If you use native input, you will find that the behavior is not like this:
```tsx
```
As described by the standard, `maxLength` only limits user input. Is this standard wrong?
> A form control maxlength attribute, controlled by the dirty value flag, declares a limit on the number of characters a user can input.
### "Unnecessary over design"
With the above questions in mind, we imagine an input scenario. Now you have an e-commerce system, set prices for products:
```tsx
```
One day your manager said that the price of our product cannot exceed $99 according to regulations, and you have to set the limit directly on the form. This change is not difficult:
```diff
--
++
```
But for existing products, we obviously cannot restrict them directly on the form. Otherwise, when the user edits the product, he will find that the price of his product has been changed. This is obviously unreasonable.
(Users will never be able to understand why the data in the background does not match what they see)
In fact, in many scenarios, components should not directly modify the actual value. Especially for input components, changing the display value without authorization will have very serious consequences.
### To be what you see
At the component library level, we cannot "guess" the user's usage scenarios, so we need to implement the processing of boundary scenarios in the most conservative way. But at the same time, we can actually do some optimization methods. For example, set the restriction to the `rules` of Form.Item, and use the form validation ability to make restrictions:
For some components themselves, it is also possible to add explicit style reminders:
For non-input custom components, you can also consider reminding users through design. For example, we can add a Tooltip to the display component:
```tsx
// Same demo we've seen before
```
Or use some other display way:
### Finally
Boundary scenarios need to be carefully handled when developing components. In complex system, upstream users may not know how your internal logic is handled. Therefore, as the complexity and usage scenarios increase, we recommend always choosing a conservative approach to the default behavior. For situations that do not meet the requirements, it can be implemented in the form of HOC or some additional Props configuration, so as to prevent developers from having too many agreements when using it without knowing it.