Baseline
Guidelines for 'must have' properties in component
Requirements Breakdown & Implications
- It must be loaded as dependency.
- Should be published as an independent package (currently as independent github repo).
- Applications import it as a library, not copy/paste code.
- Suggests versioned releases and semantic versioning.
- Can adapt cross-application theming.
- Needs a global theming system.
- Themes should be pluggable per application.
- Minimal Integration efforts.
-
Components should have sensible defaults.
-
Integration should be just:
KMultiSelectDropDown<LookUp>( name: SInfoQuestion.fContri.name, label: SInfoQuestion.fContri.question, items: state.meta.lookUps, ), -
Avoid heavy configuration.
-
- Compile-time errors for missing implementations.
-
Strongly typed with Generics/Interfaces.
-
If a component requires a handler or prop, the compiler should fail.
-
Example:
mixin KSelectable<T> implements Equatable { T get value; String get displayName; } class Country with KSelectable<Country> { //<----- Must give compile time error. Developer must override respective fields. final int id; final String name; const Country({this.id = 0, this.name = ''}); }
-
- Layout must be configurable & overridable without rewriting component internal logic.
-
Use composition over inheritance.
-
Expose builders for layout overrides.
-
Example:
HTMeta<String, Entity, EntityParentService>( builder: (_, value, __) { return Padding( padding: EdgeInsets.only(left: 30), child: Text(value ?? ''), ); }, )
-
- Partial use also should be allowed whenever required.
- Consumers can import only required components.
- For more clarification, check interdependent components.
- State management & data management must be implicit.
- Components should handle local state internally (e.g., load data, show shimmers, modal open/close, dropdown toggle).
- Allow optional controlled state for advanced use.
- Must be scalable for future expansions.
- Should follow
SOLIDprinciples. - Should follow
DRYprinciple.
- Should follow