Page and component structure

jobiqo-component.md

Summary

This document explains a generic approach to component structures in jobiqo-decoupled.

Naming pattern

Every component should use PascalCase naming in the folder (which is also required in react for components) like ResumeCompleteness but pages use a kebab-case like job-apply this is because folders map to URL's and so makes it cleaner and simpler to have proper urls like this in nextjs

Overridability

One thing that is important to consider is what parts of components we want to optimize for "overriding", and that is probably the rendering part and not so much the data fetching logic (and maybe even error and loading handling)

So for this I think a good way for us to go about it would be to inside lets say a ResumeFolderTesting component have the following folders:

• graphql : Includes any queries, mutations and fragments used for this component
• view : Which would include a ResumeFolderTestingView component which receives already the "processed" props (e.g. resume: Resume or also maybe errors if there were any). This would be tipically the compponent people might be overriding on client projects but this way all the data fetching and error handling is already being done
• components : Ofc most components might have subcomponents and its fine that they are included as well, they should tipically just follow the same pattern (e.g. a graphql folder with specific queries for that subcomponent).
• utils : If any utilities are needed (maybe some function that for example gets a logo from the job or company depending if there is a logo on the company) can be added here. Basically just helpers
• tests : Any unit testing that is needed for a component

This folder structure works particularly well with the visual studio code extension https://marketplace.visualstudio.com/items?itemName=PKief.material-icon-theme which makes it very clear when looking at a component what is happening (see attachments)

The View part I think its mostly to separate the "overridable" part from the data fetching.

Importing

its important to import { Component } from '~/jobiqo/components' because this will ensure our overrides folder works as expected.

Here is an example of what a component would tipically look like (ofc many components wouldnt have all of this)

One caveat maybe with the components subfolder is there should be only one, otherwise we get deeply nested components folders which just makes everything very confusing maybe

I absolutely agree with this folder structure. Making some kind of MVC separation makes a lot of sense. Often you only want to override the view and leave the controller (data fetching etc) untouched.

I would also name the main files the same as the component name. In the example above we would name the component ResumeFolderTesting.tsx instead of index.tsx. The advantage that it brings is that you can quickly find a component by using the files search. Otherwise every component is called index.tsx and it's really hard to navigate to it.
I use "Search by file name" (CTRL + P on my setup) to jump around files and it just does not work if everything is named index.tsx.

I use "Search by file name" (CTRL + P on my setup) to jump around files and it just does not work if everything is named index.tsx.

Yeah this makes sense to me. I would be fine with adapting that part.

The structure looks good to me. Usually we shouldn't have too many component specific sub componenets, so I don't think this will be a problem.

Making some kind of MVC separation makes a lot of sense.

I don't think you can achive a real MVC with React, since you always tie logic to the view :P

Regarding index.js:

If we don't have an index.tsx then we can't import components like this:

import {MyComponent} from '~/jobiqo/components/MyComponent'

We would have to use

import {MyComponent} from '~/jobiqo/components/MyComponent/MyComponent'

right?

MVC : Yes I think the idea for me is more like making it easier to adapt certain styling on something and when doing that not having to "care" about the whole data fetching logic.

Import : yes that would be the downside.

I dont manually type imports really so my opinion there is not too strong. In vscode it will just auto import files..I normaly just go an make sure its using the "~/jobiqo" syntax and not like "./../../../" (which usually just works in vscode so I dont have to even do that)

We would have to use
import {MyComponent} from '~/jobiqo/components/MyComponent/MyComponent'
right?

Yes, but the quicker navigation outweighs this downside for me.

Have try navigating like joao? I also just go the component and not file directly.

Do you mean navigating using the project tree? Yes, I do this because it's cumbersome using the files search.
How do you go to the component? By using your mouse?

On mac you can use you [apple]+left click on a component or left click and then go to definition or apperenlty also only F12.

On mac you can also open up the command line and enter @ComponentName:

Yep, navigating to a component by using CTRL + Click is working on Linux too.
Nice your second tip is great! I can work with that 👍 (I have bound my CTRL + P now to "Go to symbol in workspace").
If you are using #ComponentName it will search the whole workspace instead of just the file.