Possible Component Refactoring #30
Replies: 2 comments
-
I think this is an idea worth considering. Having a "helpers" or "functions" directory can be helpful for not only keeping the component files a more manageable size but also for exposing shared/sharable functions that might prove beneficial for other components. As you stated this can get a bit tricky if there is state being handled within the functions, so you would likely have to determine which functions could be removed to determine if the gain is worth the effort it takes to make this change. |
Beta Was this translation helpful? Give feedback.
-
I think this could be a good idea. I believe isTokenValid would be a candidate for this, as well as normalizeInput. If we wanted, we could also refactor some of the functions that mostly deal with Firestore to move operations not related to state outside components. I'm usually inclined to keep data access functions compartmentalized outside components, but there are certainly pros and cons (and might make less sense here where we are using react firebase hooks like useCollection inside components already). Also thinking if we do make an issue for "tidying up," perhaps it could include implementing those cleaner imports April showed us a few weeks back? |
Beta Was this translation helpful? Give feedback.
-
One thing this week has made me think is it might be useful to do a little refactoring on some of our component files which are becoming kind of large. Since we already have folders for all our components, I think one common thing that could be useful would be separating functions out into a 'functions' file (one functions file for each component) and then just importing them.
I do know some of our functions depend on accessing the component state, so would this make separating them tricky? Open to any ideas or thoughts on this.
Beta Was this translation helpful? Give feedback.
All reactions