Optimal code structure within the `code`

[G-N555]

Blocked by

• https://github.com/monstar-lab-oss/ml-frontend/discussions/3
• https://github.com/monstar-lab-oss/ml-frontend/pull/1217

While it's not difficult to isolate a single module, when it comes to aspects like authentication or themes, which involve Context and Routes, a mechanism for dynamic assembly becomes necessary.

I have created an example of solving this challenge using plop. https://github.com/jinmayamashita/sandbox-generate-react-app

[jinmayamashita]

Next action: Add CRUD module to new CLI with plop @ptrkdan

I want to try assembling an existing Module (CRUD) using plop as the next action. If successful, I would like to discuss what folder structure would be easy to assemble.

Deadline: ~ 3/6

[jinmayamashita]

cc @ptrkdan :memo: I have verified if the existing 'code' folder in the monorepo can work with Plop. 🤔

https://github.com/jinmayamashita/sandbox-generate-react-app/blob/mono/packages/start-frontend/src/index.ts

Looks like the following path can be specified successfully.

https://github.com/jinmayamashita/sandbox-generate-react-app/blob/d97d6e036d41f44ac70f412c49f8260cc650cd1d/packages/start-frontend/plopfile.mjs#L50

[ptrkdan]

Thanks, @jinmayamashita!

I've checked out your modifications and made my own additions with this PR.

I've written my observations down below:

• Prompts seem easier to write and maintain. (And prettier!)
  • If there are inputs dependent on each other (i.e. X modules are only available if you select Y framework), would it be better not to use p.group? Is there a way to reference a user input within the same prompt group?
• I noticed that you used functions and tools as names for the subdirectories. I think those are good ways to categorize the modules, although I think we'll need to write a proper definition for what is a function and what is a tool.
  • Should api modules be under function?
• It may be better to split the code restructuring into two tasks: (1) Convert the current shell script to use clack and plop with the current code structure, then (2) refactor the code structure.
  • I think it's already decided that we will be changing the current prompt method, but changing the code structure at the same time will make it complicated. I think it's better if we understood how we could utilize plop first, and then optimize the code structure afterward.

[jinmayamashita]

@ptrkdan Thank you for your input. I've also reviewed your PR for handling existing API modules with the CLI. I'm starting to get a clearer idea of how we can simplify it compared to before. 👍

would it be better not to use p.group? Is there a way to reference a user input within the same prompt group?

When using clack group, it seems we can reference previously selected values within a group called result to dynamically configure the Select.

https://github.com/natemoo-re/clack/tree/main/packages/prompts#utilities

const group = await p.group(
  {
    framework: () => p.select(),
    functions: ({ results }) =>
      p.multiselect({
        options: results.framework === 'vue' ? [] : [],
      }),
  }
);

although I think we'll need to write a proper definition for what is a function and what is a tool.

That makes sense. Initially, I thought of grouping modules to implement specific functions or features, but then I considered representing functionalities of an application like 'sending emails' or 'sharing files' as a good approach and chose 'Function' for it.

'Feature' could also work, but I'm still exploring the nuances between these two terms 😄

Should api modules be under function?

Regarding APIs, it seems a separate layer from 'function' would be more appropriate. Some functions or tests may rely on the API to some extent. However, let's continue to explore ways to maintain it easily without complicating things.

It may be better to split the code restructuring into two tasks: (1) Convert the current shell script to use clack and plop with the current code structure, then (2) refactor the code structure.

I agree. First, let's use clack and plop to modify the current start-front CLI (although there might be some troubleshooting with plop 😅). Then, with that experience, we can probably improve the code structure.

☝ Should we discuss this during today's meeting? 🤔

[ptrkdan]

I'm not sure if we'll have enough time to discuss this during today's meeting. Perhaps we can discuss this during tomorrow's (Friday, 03/07) meeting?

[ptrkdan]

Since we're halfway through March, let's see what we can possibly finish by the end of the month.

• [ ] Incorporate plop in the sandbox project
  • [ ] Determine how to utilize templates to add/remove modules, then implement
  • [ ] Execute plop within start-frontend script
• [ ] Convert current ml-frontend to use plop
  • Keep the current code structure as much as possible for this step
• [ ] Optimize code structure while using plop
  • Including determining the ideal names for folders (modules? functions? features?)

Realistically, it seems like it will take us longer than a month to complete all of these tasks. However, I think it may be possible to complete the experimentation in the sandbox project this month. I'll be taking a look at how to implement templates for plop too, so I'll post any updates here!

[ptrkdan]

TODO revision

• [ ] Determine dependencies between each modules/components
• [ ] Define module groups (modules with dependencies)
• [ ] Construct templates (handlebar) for each module group

• [ ] Incorporate into plop

  @G-N555 @seiya0914 If you have any other addition, feel free to post it here! cc: @jinmayamashita

[ptrkdan]

Modules

• React

  • API

  • GraphQL

  • RESTful

  • Routing [^1]

  • React Router

  • Wouter

  • Testing

  • Storybook

  • vitest

  • Future

  • Authentication

  • i18n (?)

    • route-based? context-based?

  • Theming (?)

Component Diagram

graph
  subgraph Legend
    NYI[Not yet implemented]:::nyi
  end

  subgraph React
    direction BT
    subgraph API
      API1[GraphQL]
      API2[RESTful]
    end
    subgraph Routing
      R1[React Router]:::nyi
      R2[wouter]:::nyi
    end
    subgraph Testing
      T1[Storybook]
      T2[vitest]
    end
    subgraph Functions
      F1[Authentication]:::nyi
      F2[i18n]:::nyi
      F3[Theming]:::nyi
    end

  %% Authentication dependencies
  %% - This may depend on which library (Firebase, etc) we implement
  F1 --> API
  F1 --> Routing

  %% i18n dependencies
  F2 -- if route-based --> Routing

  %% Theming dependencies
  %% If context-based, there may be no dependencies

  %% Storybook dependencies
  T1 --> F1
  T1 --> F2
  T1 --> F3

  %% vitest dependencies
  T2 --> API
  T2 --> Functions
end

classDef nyi stroke:#f66,stroke-width:2px,stroke-dasharray: 5 5

[^1]: Based on the sandbox repo sample

[ptrkdan]

@jinmayamashita cc: @seiya0914 @G-N555 I've made diagrams to visualize how the templates could potentially look like. I made it locally, but if there's a Miro project for this project, I could transfer it there. Let me know your thoughts, or if you have any questions!

[jinmayamashita]

@ptrkdan

Thank you for visualizing the structure of the modules. It makes it easier to grasp the overall picture.

Below are my thoughts:

About the Routing

I generally agree. However, as for pages, it seems reasonable to generate them dynamically based on the selected module.

About the API

For now, I think the API affects the Mocks and CRUD, Authentication functions. It's particularly the queryFn part. It would be ideal if we could make the structure independent, dynamic, and capable of easily replacing queryFn, but we might need to think about it a bit more.

Below, I've prepared an Excalidraw for sharing, referencing the diagram you drew. Let's continue the discussion.

https://excalidraw.com/#json=bAKOJ3f2vFZvDT3d4G_vd,cFOFPYaTEqj8UYzbkcKA4Q