waltz
waltz copied to clipboard
Add global store for common data
Description
A recent issue (#6997) has highlighted that the approach to passing common data between pages and component is not consistent. This issue should remedy this by creating a set of global stores that all pages/components can include.
Candidate stores would include:
- primaryEntityReference (or parentEntityReference)
- pageName
- filters
- user
- permissions
Resourcing
We intend to contribute this feature
We already have a page-navigation-store::pageInfo
store which is populated by the angular router or can be written to if a page transition is required.
The isNotification attribute differentiates between the notifications and the pushes.
Would need to do this for all the view pages:
- [ ] actor
- [ ] app-group
- [x] app
- [ ] assessment-definition
- [ ] attestation-run
- [ ] change-initiative-external-id
- [ ] change-initiative
- [ ] change-set
- [ ] data-type
- [ ] database
- [ ] entity-relationship
- [ ] entity-statistic
- [ ] flow-classification-rule
- [ ] flow-diagram
- [ ] involvement-kind
- [ ] legal-entity-relationship-kind
- [ ] legal-entity-relationship
- [ ] legal-entity
- [ ] licence
- [ ] logical-data-element
- [ ] logical-flow
- [ ] measurable-rating
- [ ] measurable
- [ ] overlay-diagram-instance
- [ ] person-entity-statistic
- [ ] person
- [ ] physical-flow
- [ ] physical-specification
- [ ] process-diagram
- [ ] report-grid
- [ ] roadmap
- [ ] scenario
- [ ] server
- [ ] software-package
- [ ] static-panels
- [ ] survey-instance-response
- [ ] survey-run
- [ ] survey-template
- [x] unit
These views I don't think would be required:
- [ ] actor-list
- [ ] actors
- [ ] app-asset-code
- [ ] attestation-instance-list-user
- [ ] dynamic-sections
- [ ] embed
- [ ] entity-named-node-types
- [ ] euda-list
- [ ] hierarchies
- [ ] involvement-kinds
- [ ] home
- [ ] legal-entity-relationship-kind-list
- [ ] orphans
- [ ] reassign-recipients
- [ ] recalculate
- [ ] related-measurable-item
- [ ] relationship-kinds
- [ ] survey-instance-list-user
- [ ] tag-application
- [ ] tag-physical-flow
This could be a large task.
We need to think about sections/components which can be used in different contexts on the same page (or at least differ from the parent page). This would require us to have an override mechanism, perhaps something like:
import {pageRef} from "../../../svelte-stores/globals";
export let parentEntityRef; // passed in via param
let ref = coalseceWithStores(parentEntityRef, getContext("inheritedPageRef"), pageRef)