Not yet but only because I think we're pushing hard for the 0.2 release schedule. As soon as we get this out, I think we'll able to start creating more good first issues. Perhaps let's chat about this during next week's UI contributor meeting so we can plan accordingly?

Looking forward to it!

Apologies for the delay in my response and the UC-related implementation. I've been a bit busy with other work and projects recently. The export function and export const are about arrow functions in TypeScript (ECMAScript). In the existing implementation, almost all component implementations follow the export function notation, but there are a few exceptions where arrow functions are used with export const. I thought it might be cleaner to have some sort of convention for this. It's a minor thing, but I think having consistency would make the code easier to read.

My preference is to use arrow functions, type only the function arguments, and let the transpiler infer the return type without specifying it.

Sorry for my ambiguity.

Got it... I'll defer to @yc-shawn and @jamieknight-db who have more TypeScript experience.

Hi @ognis1205! I am not overly opinionated on this, but my personal preference is to use const over function. I'll defer to @yc-shawn as well.

I think that makes sense @ognis1205 - do you think you could write up a simple design spec on what you think the refactoring should look like so we can share with the wider community?

Thank you for your response @dennyglee! I’ll summarize it in a Google document or something. Based on that, I’d like to gather input from other members as well.

Hey @ognis1205 - I'm inclined to agree with you but would love to have others chime in on their thoughts. Do you think there is a lot work involved with switching to Vite (vs. CRA) with our current UI code?

@dennyglee

Got it. I’ll include the Vite discussion in the above refactoring and coding guidelines proposal and document it. I don't think migrating to Vite will require too much effort, but let me look into it a bit more.

NOTE:

vitejs/vite#2433

@dennyglee

Sorry for not noticing. I granted comment permissions to everyone.

@ognis1205 Thanks for investigating and created a plan, but given the current project side (which is small), the improvement might be marginal. Besides, if we do want to make refactor to the project, have we consider Next.js to wrap the entire project which I believe Next.js is one of the most popular framework for React nowadays.

@yc-shawn Thanks for the feedback!

Regarding refactoring, I see it more as part of maintaining code conventions rather than merely consolidating code. For example, while utils/NotificationContext.tsx and context/auth-context.tsx use the same design pattern, I personally feel that their file naming/structuring lacks consistency. From the perspective of refactoring for code consolidation, the benefits might be limited given that this is still a small project. However, it could still yield meaningful results, such as reducing the review workload and implicitly providing implementation guidelines for new developers.

Next.js is, of course, one of the framework options to consider. While CRA and Vite lean more towards being React build tools, I believe Next.js has stronger characteristics as a full-stack React framework. (For the same reason that the project is currently small, I didn’t include Next.js in this evaluation. Additionally, utilizing features like SSR would require a certain amount of modifications.) Therefore, I think the framework choice should be based on the following decision tree:

• Need SSR/SSG, routing, and full-stack features?
  Go with Next.js.
• Want blazing-fast development and a simpler toolchain?
  Choose Vite.

In any case, I personally feel that continuing to use CRA in its current state is not ideal. While there is an option to use Vite for development servers and Next.js for production builds, there may be some feature limitations with SSR or API routes. I can also perform validations for migrating to Next.js if needed. What do you think?

@ognis1205 I don't think we need SSR at the moment, and fast dev & better toolchain is useful for sure. However, do you know if it’s straightforward to start with Vite and later introduce Next.js?

@yc-shawn

That's an excellent point. In the long run, migrating to Next.js could offer significant benefits. Since there don’t appear to be any objections to this migration, I’d be happy to explore that plan further. Alternatively, I can test it in my local repository if that works for you. What are your thoughts on this approach?

Like @jamieknight-db, I definitely want to add my vote for definitely doing this @ognis1205 - really appreciate you pushing forward with this, eh?!

I would like to contribute in case you need it @ognis1205.

@ognis1205 I'm happy to review a migration to Next.js - although I have not used it before so I'm not the best reviewer. My contributions will be limited moving forward as I've been moved to a different internal team (same one as @yc-shawn) so as long as you feel comfortable taking the lead on this and it's an effort you feel is valuable, then I say go for it 👍

@jamieknight-db

Whether someone is a good reviewer is not necessarily determined solely by their experience with a tool or framework, and I’ve been helped in many ways by past reviews. While it does make sense to consider experience when judging whether someone is a suitable reviewer, one of the great things about OSS is that it allows people to engage with unfamiliar technologies alongside others. So, I’d really appreciate it if you could continue reviewing whenever time allows.

@dennyglee @JuanPabloDiaz

I'll give the migration task a try as well. I can either work on a PR together with Juan or assist him so that he can submit the PR himself. For now, let's take on the challenge and see how it goes.

Sounds good to me!