Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ENHANCEMENT]: Refactor the whole frontend structure to be simplier #130

Open
LeoFVO opened this issue Feb 18, 2023 · 6 comments
Open

[ENHANCEMENT]: Refactor the whole frontend structure to be simplier #130

LeoFVO opened this issue Feb 18, 2023 · 6 comments

Comments

@LeoFVO
Copy link
Member

LeoFVO commented Feb 18, 2023

Description

Contributing on frontend is actually a disaster.
We are duplicating a lot of things and adding more and more useless code that will be unmaintenable in few months.
As we are rethinking our application and try to focus on major things to get done, refactor the folder structure could improve our developement flow and efficiency.

Of course there is a price to do that, and it's actually to big to be one-shot.
With @MaloPolese we are proposing to get a more simplier approach and use the same folder structure as nextjs.

We aim to reach a folder structure like this one in src folder:

  • main.tsx
  • config shared constants for the whole app
    • constants
    • routes the routers and routes definitions
  • environments infrastructure environments stuff
  • i18n
  • styles scss properties
  • app polyflix application
    • pages
    • layouts
    • contexts
    • hooks
    • styles
  • studio studio stuff
    • pages
    • layouts
    • contexts
    • hooks
    • styles
  • shared shared stuff between 2
    • components
    • hooks
    • services
    • contexts
    • types

Of course a folder structure isn't sufficient to get things orderned, we should adopt a new way to create and place component.
In each folder you will find domains specific folder
for example in shared/components:

  • common shared components between all domains
  • videos components specific to video
  • courses
  • users

To adopt this new architecture we will need to move things progressively.

@MaloPolese
Copy link
Member

MaloPolese commented Feb 18, 2023

I think that app/components is only the components for polyflix.
If you want some shared components between polyflix and studio maybe have a lib or a folder like core or shell
In this folder you can add all the components / env / hooks / api services .... shared between all app

@MaloPolese
Copy link
Member

And the idee is cool. but, right now i don't think that it have a height priority. Maybe we need to do the costing of the task first

@LeoFVO
Copy link
Member Author

LeoFVO commented Feb 18, 2023

I think that app/components is only the components for polyflix. If you want some shared components between polyflix and studio maybe have a lib or a folder like core or shell In this folder you can add all the components / env / hooks / api services .... shared between all app

Hey, I updated the structure and added a shared folder that could be made as dependancy later using turborepo.
Do you agree with the structure ? Any change to do ?

@LeoFVO
Copy link
Member Author

LeoFVO commented Feb 18, 2023

And the idee is cool. but, right now i don't think that it have a height priority. Maybe we need to do the costing of the task first

Putting in place the basis of the application should be about 1 human-day considering migrating types, services, layout and home/error pages with.

@MaloPolese
Copy link
Member

I think that app/components is only the components for polyflix. If you want some shared components between polyflix and studio maybe have a lib or a folder like core or shell In this folder you can add all the components / env / hooks / api services .... shared between all app

Hey, I updated the structure and added a shared folder that could be made as dependancy later using turborepo. Do you agree with the structure ? Any change to do ?

👍

@MaloPolese
Copy link
Member

And the idee is cool. but, right now i don't think that it have a height priority. Maybe we need to do the costing of the task first

Putting in place the basis of the application should be about 1 human-day considering migrating types, services, layout and home/error pages with.

1Md seems a bit short to me, however if you think you can do it in this delay that's cool!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment