There is a lot of boilerplate... now that the 3 main views have been fleshed out, we should be thinking about refactoring before it's too late...
A clear and concise description of todo items.
There are many utility functions that are repeated across views, we should define a src/utils for these.
We surely can use composables, e.g. for API calls, maybe for the DataTable? But for others, I'm not sure what to do e.g. all the dropdowns, Multi/TreeSelect that barely vary between Search, CompareStepI, and CompareStepII.
I don't know how to handle the different PrimeVue components that are repeated with a lot of repeated pt props? Maybe we move all this to tailoredTailwind, and keep local pt only for very specific variations.
There is a lot of "variation" in the way we handle refs/props (mostly data from the server), some are objects, "trees", arrays, etc. and they are converted to "ids" on the fly or using utility functions, etc. Most importantly, I'm not sure how best to handle empty/undefined refs/props??? This needs to be simplified.
Various items to address before this gets too big and messy...
Maintainability concerns (Tailwind custom themes and configuration, code-reuse patterns, ...). Check Tailwind core concepts and customization. See also #36
What is best practice for loading fonts? Currently, I add @layer base to the index.css.
What is best practice for html/static assets (public, or assets?)
Aims/objectives.
There is a lot of boilerplate... now that the 3 main views have been fleshed out, we should be thinking about refactoring before it's too late...
A clear and concise description of todo items.
There are many utility functions that are repeated across views, we should define a src/utils for these.
We surely can use composables, e.g. for API calls, maybe for the DataTable? But for others, I'm not sure what to do e.g. all the dropdowns, Multi/TreeSelect that barely vary between Search, CompareStepI, and CompareStepII.
I don't know if plugins could be useful?
I don't know how to handle the different PrimeVue components that are repeated with a lot of repeated
pt
props? Maybe we move all this totailoredTailwind
, and keep localpt
only for very specific variations.There is a lot of "variation" in the way we handle refs/props (mostly data from the server), some are objects, "trees", arrays, etc. and they are converted to "ids" on the fly or using utility functions, etc. Most importantly, I'm not sure how best to handle empty/undefined refs/props??? This needs to be simplified.