The problem / idea

I am working on front-end a lot and what I find really convenient is that they're component-based structures. This is common in Angular, React and Vue.

E.g. a component 'user' has the following structure

user/
   user.component.html
   user.component.scss
   user.component.test.ts
   user.component.ts
   user.translations.ts

What is so convenient about this? Well If I want to reuse this in another project, i can just move the 'user' component because it has everything it needs inside that folder

How does feathers v4 currently look

Example:

src/
   hooks/
     isAdmin.ts
   models/
     user.model.ts
   services/
      user/
         user.hooks.ts
         user.service.ts
test/
   services/
     user.test.js

My proposed solution

src/
   services/
      user/
         hooks/
            isAdmin.ts
         user.hooks.ts
         user.service.ts
         user.test.ts
         user.model.ts

Why / potential use cases

• Well if a new developer asks, where do I find x for user?
  Currently you can answer it depending on what 'x' is, if it's test it's a different place, if it's hooks it's a different place.
  With the new proposed architecture, it does not matter what 'x' is, you can always point to the user service to find everything regarding the user
• If a developer checks out your project, and find a really cool service named 'somecoolservice'. With the new proposed architecture you can say, yeah sure go ahead and just copy 'somecoolservice' into your project

Potential downfalls

• Where would you place a hook that is useful for multiple services ? Do you keep 'isAdmin' in user service and require it from there in other services, or create a shared / lib folder? This can be hard to answer
• Where would integration tests and tests that not only apply to one service be placed? This can be hard to answer