Limitations and workarounds about the number input.

From the UK government:

Et ce sera bien pratique!

Laravel suit l'évolution et peut être utilisé avec Vite. Ici un exemple en intégrant Boostrap.

Similar to useFetch in vue

1. When you need to release a breaking change—any breaking change—you do it in a major version. Period. No excuses.
2. You need to find a different way to communicate more significant project-wide changes and improvements. Major version numbers can’t do double duty as both breaking-change indicator and marketing hook.

About the second point, I would argue that giving an name is greater :D
Ubuntu uses it... Hahaha I read it as I write it.

Une liste des méfaits de MacKinsey, juste pour info sous le coude

Petit rappel: Déclaration des droits de l'homme, article 35 :

« Quand le gouvernement viole les droits du peuple, l'insurrection est, pour le peuple et pour chaque portion du peuple, le plus sacré des droits et le plus indispensable des devoirs. »

I find it hard too :/

Rule of thumbs:

1. Show errors immediately if issues are severe
2. Late validation is almost always better
3. Validate empty fields only on submit
4. Reward early, punish late: if a user edits an erroneous field, we should be validating immediately, removing the error message and confirming that the mistake has been fixed as soon as possible (reward early). However, if the input was valid already and it is being edited, it’s probably better to wait until the user moves to the next input field and flag the errors then (punish late).
5. Validate after a copy-paste
6. Allow users to override inline validation
7. Just in time validation
8. For short forms, consider validation on submit only. For complex forms, use the task list pattern

The infer keyword only works within conditional types. It defines the type depending of another one.

Some use cases:

• extract type from promise
• extract function return type
• extract multiple candidates