Make the dashboard into a seperate folder within frontend/src

b24johka commented

2026-04-28 07:23:58 +00:00

Collaborator

The dashboard was implemented as a component which is wrong, the components folder is supposed to consist be reusable frontend components.(dropdowns and toggle buttons is perfect example). Right now dashboard is being broken out causing the components folder to be bloated with dashboard specific elements.

EDIT: The decision has been made to hold the implementation until the temporary merge branch, i will note the developer about trying to prepare as much as possible in order to make the change as smoothly as possible.

The dashboard was implemented as a **component** which is wrong, the components folder is supposed to consist be reusable frontend components.**(dropdowns and toggle buttons is perfect example).** Right now dashboard is being broken out causing the components folder to be bloated with dashboard specific elements. EDIT: The decision has been made to hold the implementation until the temporary merge branch, i will note the developer about trying to prepare as much as possible in order to make the change as smoothly as possible.

a24vinla added the

cleanup

label

2026-04-28 07:32:34 +00:00

a24vinla commented

2026-04-28 07:46:57 +00:00

Collaborator

Might be a good idea to do this during merge

b24johka commented

2026-04-28 07:51:34 +00:00

Author

Collaborator

You mean afterwards?

a24vinla commented

2026-04-28 08:00:30 +00:00

Collaborator

During, when we fix inevitable issues in the temp branch

👍 1

b24johka commented

2026-04-28 08:24:05 +00:00

Author

Collaborator

Alright! i think this is a good idea.

b24erika was assigned by b24johka

2026-04-28 08:24:18 +00:00

b24erika was assigned by b24johka

2026-04-28 08:24:20 +00:00

b24erika commented

2026-04-28 08:56:20 +00:00

Collaborator

Work in progress

bild.png

91 KiB

👍 1

b24erika commented

2026-04-28 09:16:03 +00:00

Collaborator

Perhaps a review before "implementing" the file-system? @b24johka @a24vinla

frontend-mapping-example.png

79 KiB

👍 1

b24johka commented

2026-04-28 09:31:14 +00:00

Author

Collaborator

The main index file in the frontend should probably not be moved. its the starting point for the whole front end module. The major concern with having multiple index files is if they're heavily nested they can interfere with each other. I can only find 2 index files in the frontend directory, where would the third be located?

Other than that i think all of the changes are reasonable, the diagram is showing which files are being moved from the current system. are we gonna make one more diagram showing how the system after the change should look?

The main index file in the frontend should probably not be moved. its the starting point for the whole front end module. The major concern with having multiple index files is if they're heavily nested they can interfere with each other. I can only find 2 index files in the frontend directory, where would the third be located? Other than that i think all of the changes are reasonable, the diagram is showing which files are being moved from the current system. are we gonna make one more diagram showing how the system after the change should look?

b24erika commented

2026-04-28 09:43:23 +00:00

Collaborator

My bad for not being clear, there is no main index file, my suggestion is to combine the 3 existing to have an main index within the frontend folder that specify all file paths (imports).

b24erika commented

2026-04-28 10:38:47 +00:00

Collaborator

@b24johka wrote in #602 (comment):

The main index file in the frontend should probably not be moved. its the starting point for the whole front end module. The major concern with having multiple index files is if they're heavily nested they can interfere with each other. I can only find 2 index files in the frontend directory, where would the third be located?

Other than that i think all of the changes are reasonable, the diagram is showing which files are being moved from the current system. are we gonna make one more diagram showing how the system after the change should look?

One under src, one under features, one under pages and last under components. The one under src do have some rendering which we could keep as it is.

@b24johka wrote in https://git.webug.se/Andras/BoundlessFlowCampus2K/issues/602#issuecomment-6261: > The main index file in the frontend should probably not be moved. its the starting point for the whole front end module. The major concern with having multiple index files is if they're heavily nested they can interfere with each other. I can only find 2 index files in the frontend directory, where would the third be located? > > Other than that i think all of the changes are reasonable, the diagram is showing which files are being moved from the current system. are we gonna make one more diagram showing how the system after the change should look? One under src, one under features, one under pages and last under components. The one under src do have some rendering which we could keep as it is.

a24vinla commented

2026-04-28 10:40:17 +00:00

Collaborator

I think this is a good idea! Seems incorrect to have multiple index files when we could combine them instead!

b24erika commented

2026-04-28 12:08:09 +00:00

Collaborator

Should I start to make the folders missing so that we can arrange files after merge or do we need to add something? @b24johka @a24vinla

b24erika commented

2026-04-29 11:07:54 +00:00

Collaborator

Implementation is done, no "big" index file made and a pull-request has been made.

Implementation is done, no "big" index file made and a [pull-request](https://git.webug.se/Andras/BoundlessFlowCampus2K/pulls/645) has been made.

b24erika added reference 602-new-file-structure

2026-04-29 11:07:59 +00:00

b24erika added the

frontEnd

needs review

labels

2026-04-29 11:08:10 +00:00

hGustavs commented

2026-04-29 12:32:08 +00:00

Owner

Good instinct to do this type of refactoring between / inside merge.

Once the code is more stable and we start deploying this type of refactoring may be very complicated.

Good instinct to do this type of refactoring between / inside merge. Once the code is more stable and we start deploying this type of refactoring may be very complicated.