Functional components prototype

[filipesmedeiros]

This is a prototype/preview of what functional components could look like, potentially.

I want to stress that this change would be mostly made incrementally, as needed, and not all at once. There's specific places where it would be beneficial to have functional components, for example in places where it's more semantic to use useLocation to navigate (as I did in the Home example).

Two things to note:

1. I did not spend too much time doing a deep restructure of the components, optimising network calls, etc. I just wanted to show you how it could look/feel like, first. But, for example, we could be using Context to pass down auth/user data, instead of drilling down with props.
2. I think there's also room for simplification on the auth flow (just regarding the component structure, not the UI itself). Overall, I find MUI somewhat "noisy"/verbose, so that might be it, and not the component structure itself
3. I really think that, in my area of comfort that is the frontend, there is room for architectural and tooling simplification. I tried to update React to v19, to use the use function/hook, but I got hit by a bunch of errors from Typescript, ESLint, etc. that I couldn't solve. I also am not really experienced with working with these sort of "workspace" repos, where tons configuration is shared among many parts of the project. E.g. I don't fully understand why the app directory has both a .eslintrc.js and a eslint.config.js files, and simlinks to the root tsconfig.json and also has a tsconfig.browser.json. This is tangential to the PR, of course, but it's the kind of thing that I believe slows down the entry of a new developer (like me! eheh)

How to analyse at this

I think the best way to take a look is to ignore the PR view on Github, and just first look at the new file on its own. Get a feel for it, and how the semantics look and feel like. Then maybe side-by-side with the old version.

Let me know what you think :)

[filipesmedeiros]

As an added note, I think doing this would be a great help into frontend maintainability. For example, the issue with #110 seems to be harder to solve due to somewhat intricate component structures and state logic.

Please keep in mind I don't want to blindly criticise your (and other contributors') work, @bpowers! I am just trying to help the way I know how, and I highly appreciate the work you've done here: it's spectacular what a tiny group of people are able to do with dedication. You are welcome to reject or push back on any of these ideas, of course.

I am just trying to find a way to "ease into" the project to implement some of these features we all(?) seem to want, like multi-selection, run management, etc.

[bpowers]

this broadly looks reasonable to me! One concrete thing is that after your Login.tsx changes I can't enter text in the email field that pops up after clicking "login by email"

[filipesmedeiros]

@bpowers fixed! You were totally right, I moved a bit too fast here :P

Should be good now. As an piggy-backed changed, I delegated even more work to the browser (client-side validation of fields) and removed some unnecessary state because of that. The component is simpler and the functionality should be the exact same, except that the messages look "browser-default". I personally don't mind this, but you should give it an OK for use to move forward with this choice from now on.

[bpowers]

great - I will look closer tomorrow. Happy to have more client side validation! we'll need to keep server side validation as well. You didn't remove anything, so I think we're on the same page, just wanting to say it for posterity

[filipesmedeiros]

Yeah, for sure! I did not change any of the client/server responsibilities at all! I just moved the client-side ones from the application code to the browser :) Everything should be checked on the server, that's a given!

[filipesmedeiros]

I'll open this so it can be merged, and then I'll continue refactoring stuff bit by bit, as needed!