mosharaf13 / fleet-searcher

Upload a CSV file containing keywords and view google search stats
1 stars 0 forks source link

[Question] Why placing all component code in `setup` method? #33

Closed olivierobert closed 1 year ago

olivierobert commented 1 year ago

Issue

https://github.com/mosharaf13/fleet-searcher/blob/dc70169cf85dd164c55b9b25b355c34390aa04f2/resources/js/components/FleetSearch.vue#L102 is failry long 🙈 Why not using the lifecycle hooks mounted and event handler methods?

mosharaf13 commented 1 year ago

When I started developing in vue 2 back in mid 2018, I noticed that it's easier for components to get bloated if I am not careful designing the component. Since then I have looked for ways to make my components cleaner and easier to read.

Ever since composition api came out, I have been experimenting with this function based approach of writing logics inside the setup method. Using mounted, computed, and other hooks inside it.

My motivation for this came from this article. It suggests using the hooks and event handlers inside this setup method and return what will be used inside the template.

After splitting the FleetSearch component the setup methods for each component should become smaller.

In some ways, this setup method allowed me to keep all of my variables and methods inside one method. But, it sometimes becomes trickier to organize and adhere to a standard while using hooks and methods inside it, leading to a bit messy code.

I believe its a preference thing and all the members inside our team should agree on which api we are going to use (options/composition).

What's your suggestion on this? Should I use the Options API and use lifecycle hooks separately, or should I use the Composition API and organize the hooks and methods a bit more elegantly?

olivierobert commented 1 year ago

Thank you for clarifying your motivation, as it is based on using the COmposition API vs. the Options API. As the team primarily uses React, my expertise in Vue JS is more limited 🙈 Using the Composition API is fine but indeed, the code should be restructured into different methods (as in the example provided) to make the code more readable, maintainable and testable (each method could be tests separately, for instance).