praise: This is looking really nice!

praise: nice, this approach seems great to me.

Question on code conventions --> are we going to adopt using function instead of const arrow fns for pure functions in v2? Stylistically, it's my preference too. WDYT?

I've always preferred arrow functions but I don't know if there's a good reason to anymore. I think you just have to use function for generics. What do you prefer about them?

These can be safely ported over to arrow fns:

const genericFn = <T,>() => {
  // impl
}

What do you prefer about them?

Simply the style: when all fns look the same, my brain is happy. I dislike missing braces/early returns and having to scan the difference between a non-fn const and a fn const.

Visualized, I mean:

// my brain is happy with this

const myVar = "myVar"

function thing() {
  return "thing"
}

[1, 2, 3].map((num) => {
  return num + 1
})

if (myVar) {
  thing()
}

// my brain is not happy with this

const myVar = "myVar"

const thing = () => "thing"

[1, 2, 3].map(num => num++)

if (myVar) thing()

My brain has to do extra processing to understand version 2, even though it's shorter in length. I think this is due to how much I can "read between the lines". In version one, things are blocked in a way that's easy for me to interpret in the background; ultimately I think I "absorb more information per eye scan" or something like that. In the second version, I often find myself double-passing/re-reading some blocks to understand the big picture.

I won't die on any of these hills, because my brain and its preferences don't get to dictate these things; we make those decisions together as a team. At the end of the day, consistency is best to shoot for, and we already use the arrow fns, so I think we should convert these over to be arrow fns.

The only time we should reach for function is for special cases around scoping this inside the function

Oh thanks, didn't know the trick for making the generic work with an arrow function. But yeah I see your point! I'm down to switch to function.

I'm going to put this issue on the list of things to discuss at a future FE V and stick to arrows for now.

@vapurrmaid @kylecarbs do we want validation on the password?

This is the same as it is in V1, I'm inclined to circle back to it later since it's separate from this change and would need some tests. I think that overhead warrants it as a separate concern.

There's also potentially the desire to have the validation regex come from the backend so that it's centralized. We can brainstorm more on that over gap week next week.

cc @f0ssel @deansheather @johnstcn @coadler --> we've all spoken about centralizing things in the backend at some point in a recent breakout session, would love to noodle on moving validation/regexes into the BE as well, to see if it's a worthwhile idea to explore.

I think in this case if we just make it so the backend does the validation and then returns a per-field error that the frontend can parse then it's the same effect without having to do weird stuff like returning regexes from the backend

Worth considering, but we should also think about the user experience of having to submit your form before you find out that it's invalid.

Worth considering, but we should also think about the user experience of having to submit your form before you find out that it's invalid.

• Idea 1: We could just leverage the OpenAPI pattern field for stuff like regexes and use auto-generation magic to keep validations in sync across FE and BE. This wouldn't let us do fancy stuff like interdependent fields though.
• Idea 2: We could ensure that the backend accepts a parameter validate (or whatever you want to name it) that will signal the backend to only perform field validations and no other action.
  • Note: we won't be able to validate everything, and this also incurs additional request overhead as I'd imagine we'd want to trigger a fresh validation request on every change in the form.