Niles Brandon qarthandgi

Next Set of Laws... ASP.NET MVC (Coming Soon)

🤖 Advanced Vue.js Requires Communication, Experience and Wide & Deep Thinking 💪

SSG-first! Need More? Expand to SPA, then SSR. Don't be dictated by trends. Understand business needs and sensibly conclude an architecture.
Even if your use case does not warrant a build step....consider it! Utilizing SFC (Single-File Components) is imperative to abiding by SOLID principles and coding in Vue's philosophy.
Composition API > Options API. No Discussion needed. After countless Vue 2 ➡️ Vue 3 migrations, converting to the Composition API has been the single best benefit to developer productivity, code organization, and utilizing best software architecture principles.
Utilize Pinia early for state management. Don't resort to hand-rolling state management composables, data will become scattered and multiple sources of truth will emerge.
Utilize null and undefined values on Attribute Bindings to dynamically remove HTML attributes from elements. It's one of those swiss-army knife tricks that helps in advanced templating. (Careful of the empty string ''.)
Dynamic Arguments are a killer feature for abstract template creation polymorphic components - particularly in complex SPA applications with high interactivity & complexity, such as 3D, blueprints, maps and more. (I'm thinking custom event listeners, defined by outside state rather than defined on the template.)

<button type=submit @[neededEvent]="triggerPolymorphicEventHandler">Create Model</button>

Utilize generic definitions over type annoations when utilizing TypeScript with ref()

Preferred

const name = ref<string | array>('niles')

Only use when your type is needed in other TypeScript logic

const name: Ref<string | array> = ref('niles')

Events-Driven Architecture is awesome...until it isn't.
Embrace Modules, Engines, and other monolithic organization units
Interfaces are your friend. They provide clarity, extensibility, and make documentation easier.
Use the Service Container to your advantage. Think about how your classes, engines, and service classes will be used via the service container at the beginning.
Model Events are dangerous. I know it's controversial...but I've seen it fail too many times. If you do it, it should always be class based. It makes testing against it easier - architecture testing via Pest.
Utilize Model Permission Guards Extensively. Lock down database access based on roles and permissions.
TDD is King. I know it sucks, but you will be better off.
Be extremely wary of Livewire, it is tempting to transfer business logic to Livewire view classes.
Be extremely wary of Inertia.js. It makes life easy at the beginning. Some of its limitations cause problems later on.
Embrace the Manager Pattern, it's powerful...if you use it for good.