Issue table refactoring

baupen / web

Issue management for construction sites

MIT License

3 stars 2 forks source link

Issue table refactoring #443

Closed famoser closed 3 years ago

famoser commented 3 years ago

The state of the issue table is directly kept within the issue table. This introduces complexity when external need to change which issues are displayed. This is the case in the foyer with registration: Registered issues are removed from the table.

The issue list must be loaded by the parent to allow these interactions.

famoser commented 3 years ago

The issue table inherently holds a lot of complexity. Refactoring it is risky, hence without a clear objective will postpone this.

Potential targets for future refactoring:

[ ] single object should hold filter state (instead of filter & filterConfiguration)
[ ] align template and default names
[ ] refactor loading into mixin to reuse in register, foyer and filtered

Still open questions:

[ ] how to detect if default filter is active in filter

famoser commented 3 years ago

Relinked in related issues, closing