everdimension

They've been blurring a lot lately

Come on, it's about replacements. They're easier to express (meaning literally easier to type out) with the author's syntax

Great project

Title sounds like a dream, but I don't really see it happening yet. I honestly think you have to be retarded to put a touchscreen into a car. But they don't seem to be making less of those

While I mostly share the same opinion and tend to agree with your conclusion, strictly speaking your observations do not prove that the original doctors were wrong. One could argue that the "poorer" dentist offices are like that precisely because they are worse at treating patients and either aren't trained enough to notice the problematic signs or just care less because they have a lot of patients and aren't paid a lot.

I really wish these exams and observations were "provable" somehow and much more strict, and weren't a matter of collecting second, third and fourth opinions.

I addressed this elsewhere in the comment section, but there's not much "react" going on in the article. I do think that JSX is very expressive and the concern I cover mostly involves the declarative "component" model for writing UIs. It's not react-specific.

totally And if they fix it, it'll be fixed for everyone

Thanks, that's quite interesting and insightful! Thank you for sharing

The fact that something provided by the browser can fail accessibility requirements is definitely ironic. We're always taught that the motivation to "use the platform" and "follow semantics and semantic elements" is partly to satisfy the accessibility concerns.

I still think it's worth to leverage the native validation mechanisms.

* You don't have to use the native validity tooltips for the error messages. You can read directly from the input's ValidityState (input.validity) and render the message however you like and show multiple errors if you need to

* The browser can improve and you will benefit from using a standardized approach

The fact that "not using popups" supposedly breaks a11y sounds weird, though. But if you need to respond to an audit then this is the way you can go.

Errors that do not belong to a particular field

These are indeed interesting! There are techniques to handle those, too. In my project I have a "HiddenValidationInput" component that renders an invisible readonly input that serves the purpose of rendering a custom error that doesn't belong to any other field. It's in fact quite a pleasure to use because you can just conditionally render it.

The custom validity API is imperative and cumbersome to use

Absolutely agree on this one, and handling this is exactly what my article is about. And I really hope that this part will improve in time, too

Yeah this is exactly what I'm writing about in the article :)

This article ultimately supports this by showing us exactly how half-baked this particular browser feature happens to be.

In a way, yes. I do think there's a lot to improve from the browsers' side. I guess what I'm trying to say is that the "half baked" solution is also not quite as bad as "no solution" and 1) it can be improved, 2) it really can be used today if you know "how to cook it right"

I totally understand this. Having DOM elements as an entry to some API isn't the best thing.

But firstly, I would consider what you're missing when you abandon native validation

* On submit, the first field that needs attention gets focused automatically

* Error messages for semantic attributes are localized automatically by the browser

* The native message tooltip are actually nice and their placement is handled by the browser. They aren't the best fit for any design system, but for many products they are way nicer than custom implementations.

* Possible styling using CSS pseudo-classes such an ":invalid" or ":user-invalid"

In the end, I do think that the developers would benefit from a more explicitly exposed API for this. Just like we got the "new URL()" constructor, but earlier we had to create an anchor node, fill in its "href" attribute and then read the anchor properties to get to the parts of the parsed URL.

That's great advice!

I also dislike the "character rejection" mechanisms, even though many people love it and products often ask to implement it.

To add to the possible solutions mentioned in your article, I'd add the "pattern" attribute. You can do something like this:

<input pattern=".{0,6}" />

This will allow input of any length, but show a warning then the value is longer than six characters.

That's weird! Have you tried submitting the forms in the examples? The custom messages are supposed to be shown in the native browser validation tooltips. The support for those is quite good! Even on mobile browsers

The HTML is created using JSX, that's true. But the validation that the browser performs is part of the HTML behavior.

The API I'm proposing would indeed bring much more benefit when used in a declarative way. That's the point I'm specifically trying to convey in the article.

I don't think I understand how it would be "worse" for plain JS and HTML though. Would love to hear your thoughts.

Actually, there is one possible concern. When HTML is returned by the server includes inputs with set "custom-validity" attributes and this HTML gets open by a browser with no javascript enabled, this would make the input "stuck" in an invalid state. This is an important edge case to consider but I do believe there is a resolution that would satisfy everyone

Yeah, I am aware! Thank you for the concern :) I did address this in an adjacent comment, but I'll say again that I did contemplate over using JSX or not. Also yes, it may have been a good idea to add a disclaimer for the fact that the code I'm showing is JSX, but honestly there are so many other disclaimers I had in mind, all of them together would make the article twice as long and much more boring

It's definitely true that many developers would benefit a lot from learning more about the basic HTML and the web platform. But I refuse to support the notion that this is somehow React's fault.

In my personal experience, react allowed me to rely more on the native web platform APIs, not less, than other frameworks (at the time that I switched to react)

Sorry to disappoint, I did hesitate over this. But JSX is honestly very nice to read and also I didn't want to leave the impression that opting in to native form validation somehow forces you to not use javascript. And combination of javascript + html is, again, very nicely expressed with JSX.

The concepts are obviously easily translated to other component frameworks, but they also do apply to pure HTML and vanilla javascript.

The problem I am highlighting in the article is the absence of a declarative nature to the Custom Validity API, so I think it makes sense to use a declarative component approach in code examples

Yeah well I promise it does read nicely when there's formatting which HN comments do not allow :)

That's exactly the case where the "customValidity" attribute shines!

I have nothing against regex and the "pattern" attribute is the way to go for many cases, but having this is an alternative is also very nice:

const valid = value.length => 4 && isAlphanumeric(value); return ( <Input value={value} customValidity={valid ? 'at least 4 alpha characters' : ''} /> )

Even in jsx its not required to add a boolean value

Absolutely true! But I like to do it because I personally think it reads more nicely and is more explicit and that's what I do in all my projects. But it is indeed a matter of taste and I have nothing against code that follows the convention to omit the "true" value.

Couldn't have said it better!

Great answer, exactly! Client-side validation isn't meant to remove the need for the server-side checks

there's an enormous amount of other validation scenarios they don't cover

Can you provide examples of those? Genuinely interested as I'm on a quest of creating a list of recipes that show that native form validation can be just as capable as custom validation libraries

That's totally true! Invalid states shouldn't be shown sooner than necessary

It's just that for the demos in the article it makes sense to show invalid states as soon as possible, but for a nicer UX in real apps you need to take into account "touched" and "submitted" states for the form and per input

For the demos I wanted the reader to know at a glance when our validation code takes effect and this obviously comes at a conflict with demoing a fully "real-world" behavior

You usually create debounced inputs for that. This is similar to the autosuggest and typeahead inputs and comboboxes: sending requests to the server in response to an input change isn't something unusual

I think the problem here is not as much with the absence of custom styling, because you can quite easily read the native "validity" state of the input and render it however you want.

The problem is that it's quite tricky to correctly subscribe to the changes of this validity state. There are indeed some validity events being dispatched, but unfortunately not always. Updating form state programmatically (such as calling "form.reset()" or setting input value via "input.value = '...'") doesn't trigger these events.

I think this is a separate good topic for investigations and for suggestions to the web platform

It does suck, but I think not for the reasons you mention.

I truly believe a nicer API would motivate developers to use it, and if native validations satisfy the product requirement, their styling does become a lesser concern.

But surely styling is still important, but another great topic to write about is the fact that you actually can opt-in to showing native validity errors in a custom way!

That's actually a good argument for the point I was trying to make. Existing validity attributes such as "pattern" are cool, but not enough.

E.g. the "repeat password" example is actually achievable without "setCustomValidity" by using the "pattern" attribute. For that, you would have to dynamically construct a RegEx out of the value from the first input. I didn't want to make the article too long by comparing the solutions, but the point is, with the "customValidity" you see how much more eloquent and easier to read the validation is. So a nicer API here makes all the difference

The "15 word minimum" constraint would look so much nicer as "value.split(/\s+/).length >= 15".

Completely agree with "give people a better office" and completely disagree on what a good office is. But instead of arguing on details, I want to say that as always, people are different. Sometimes polarly different.

I love an open space which is a bit loud rather than quiet. It actually makes me feel more privacy than a quiet room full of people.

But here's a recipe. Create an amazing office and don't force anyone to go there! No "once a week" rules or similar. Make it completely voluntary. And see what happens.

A great office located closely, ideally walking distance, where you can discuss ideas and offtopics with your coworkers, have great coffee, not worry about snacks and stuff is like visiting an all-inclusive hotel, but for work. This statement isn't true for everyone. For some people working from home will always be better. Don't force them to change. But see what happens when you have an inviting place that's available for people to visit for as long and for as short as they want.

IIRC promises already have a `map` method which is synonymous to the `then` method.