Create an app & route based structure in Marsha frontend

[mbenadda]

Feature Request

Is your feature request related to a problem or unsupported use case? Please describe. As we started working on the Marsha site, we asked ourselves if it should live in a separate directory from the Marsha LTI app. We decided against it as that added complexity while doing nothing for tight coupling between the two apps.

It has not caused issues thus far, but contributes to Marsha having a very inflated components directory, which some of us find creates confusion around what exists and what is available for what kind of use case. (Feel free to edit the issue and elaborate here @kernicPanel).

As we plan to add a third kind of Marsha app, as an LTI app dedicated to Big Blue Button, we're starting to see how keeping everything together might entangle our apps as we build them.

Describe the solution you'd like We had a discussion with @sampaccoud and @kernicPanel about this during standup. Our proposed solution would be to separate between actually common components, like a design system, and route-specific components.

// Contents of the frontend/ directory
apps/
  lti/
    index.tsx (old LTIRoutes.tsx)
    common/
    DashboardDocument/
    DashboardVideo/
    ...
  site/
    index.tsx (old SiteRoutes.tsx)
    common/
    PlaylistView/
    VideoView/
    ...
  bbb/
    ...
components/
ds/
  Icon/
  Loader/
  Player/
  VideoList/
data/
i18n/
...

Rule of thumb for organizing components:

• Components tasked with rendering a given route go in the corresponding app's root folder ($1)
• Sub components specific to one of the $1 components go into that component's folder
• Components that will be used in more than one of the $1 components in the same app go into the common/ dir for that app (for instance a big-blue-button component used in more than one place in the bbb app)
• Components that will be used in more than one app need to make sure they're thoroughly reusable and go into the design system (ds/)

This would create a guidance for where to put what we're building and make it clear what is available for reuse. Developer's judgement can of course always put components directly in common/ or ds/ even if they're only used in one place.

For now this enables us to keep everything tight and run a single build with a single entry point that async loads the correct app, as we have been doing. We can move to multiple outputs or even multiple builds later on as needed after the migration is complete.

Discovery, Documentation, Adoption, Migration Strategy We can create the new directories and move existing components that match them into them. Everything that needs refactoring stays in components/ for now and acts as to-do list items to migrate progressively.

The initial PR is just moving files and updating import paths (no code refactoring) but it needs to happen at a time when our PR backlog is mostly empty to avoid disrupting Marsha development.

Do you want to work on it through a Pull Request? We'll be waiting for @lunika's input and ideas before we do anything on this topic.

[kernicPanel]

Thanks for this comprehensive proposal @mbenadda , great work :+1:

I'm just wondering if we should keep index.tsx files elsewhere than src/frontend/index.tsx. Maybe it would be more clear if we use more descriptive names, like app/site/routes.tsx ?

[kernicPanel]

I'm closing this, as it is clearly outdated, and the refactoring has been done in an other way.