A couple question about the project

[gutisalex]

hey, first off big shout out to the devs making this project public available... I think its really good for learning "best practices"! And I know "best practices" are always debatable but I like almost all the ways how its done in this repo. But I have a couple questions about some things:

1. I see you don't use any barrel files for your components. You just use index files. Why you did this, I think I understand. Its less work to maintain, its better for performance, etc... I read a whole article about it here. But you still use one for your hooks. But you don't use it for util? Is there a reason behind that?
2. You are using *.mjs files for all your tests. There are a couple pros for this but also some cons like missing autocompletion, typesafety, ect. What are your reasons that you use mjs here?
3. Why using *.mjs for almost all config files? Just because module js? You still have some configs in ts or json...

[AugustinMauroy]

I see you don't use any barrel files for your components. You just use index files. Why you did this, I think I understand. Its less work to maintain, its better for performance, etc... I read a whole article about it here. But you still use one for your hooks. But you don't use it for util? Is there a reason behind that?

This was done when the server component and the two ‘environments’ were introduced. The fact of having a large file is to separate the server from the client. But yes, it's not very useful.

You are using *.mjs files for all your tests. There are a couple pros for this but also some cons like missing autocompletion, typesafety, ect. What are your reasons that you use mjs here?

That's what we call a ‘religious debate’, where everyone defends their own point of view. Between using .js and .mjs, on the infra web we use mjs everywhere because it validates the format.

Why using *.mjs for almost all config files? Just because module js? You still have some configs in ts or json...

About ts #7148

[gutisalex]

ok nice thanks for the explanations...

just one more: Why are you using FC for your components over named function

const Foo: FC<FooProps> = ({children}) => {...}

instead of

function Foo({children}: FooProps) {...}

less imports and the way nextjs recommend it in all their examples... Personally I rather try to not use arrow functions unless its really necessary for some reason! Positioning dont matter in normal functions but they do in arrow functions... but maybe thats also debatable ;) Thank you very much! Appreciate your time...

[AugustinMauroy]

It's easy it's just because we use react. React represent Component with Function so to type it we use FC that mean Function component. so what next.js "recommend" for react isn't right