praise: This is looking really nice!

praise: nice, this approach seems great to me.

Question on code conventions --> are we going to adopt usingfunction instead ofconst 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 usefunction for generics. What do you prefer about them?

These can be safely ported over to arrow fns:

constgenericFn=<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-fnconst and a fnconst.

Visualized, I mean:

// my brain is happy with thisconstmyVar="myVar"functionthing(){return"thing"}[1,2,3].map((num)=>{returnnum+1})if(myVar){thing()}

// my brain is not happy with thisconstmyVar="myVar"constthing=()=>"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 forfunction is for special cases around scopingthis inside thefunction

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 tofunction.

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 OpenAPIpattern 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 likeinterdependent fields though.
• Idea 2: We could ensure that the backend accepts a parametervalidate (or whatever you want to name it) that will signal the backend toonly perform field validations and no other action.
  • Note: we won't be able to validateeverything, 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.