Fet/demo copy date functionality #988
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…nto FET/demo-copy-date-functionality
- still needs wired up to an actual view but the app itself should be good to go for testing once that’s done.
…es in the state etc
- fixes a bug with state not updating correctly for entity map.
- returns values of object usable for cloning via a factory.createNew call.
…nto FET/demo-copy-date-functionality
- fixes a bug with state not updating correctly for entity map.
- returns values of object usable for cloning via a factory.createNew call.
- remove unnecessary prop destruct - remove errant semi-colon
…nto FET/demo-copy-date-functionality
- This is already removed in the `FET/add-relation-type-awareness…` branch but there must have been a bad merge resolution somwhere because it keeps popping back up in this branch (so I hve to redo it).
props was flawed becuase its initial value would always be true on re-render instead of retaining the set value via the withSelects.
10 tasks
- tests needed updates due to changes in defaults and fixtures for other tests.
…nto FET/demo-copy-date-functionality # Conflicts: # assets/dist/build-manifest.json # assets/dist/ee-components.862d05bcd21aee9a8e46.dist.js # assets/dist/ee-components.a695ce319583d44ee305.dist.js # assets/dist/ee-components.fd9c0ddbaa8c1b4df62b.dist.js # assets/dist/ee-data-stores.17fa41b8f7e48f188880.dist.js # assets/dist/ee-data-stores.5730d2796de06a3cc59e.dist.js # assets/dist/ee-data-stores.ddd7227091cc0b743257.dist.js # assets/dist/ee-model.1c92d31063e9885dfbdd.dist.js # assets/dist/ee-model.2968981fc37f7c6f807a.dist.js # assets/dist/ee-model.7d8f31eb6ca97256617c.dist.js
nerrad
commented
Mar 4, 2019
| ); | ||
| } | ||
| return { onDateClone }; | ||
| } )( DatesList ); |
There was a problem hiding this comment.
Note how DatesList (which is responsible for outputting the list of datetimes and the clone button) has the withDispatch HOC wrapping it. This HOC primarily takes care of the clone button behaviour which when triggered:
- Retrieves related tickets on the datetime clicked.
- clones the new Datetime entity from the one clicked and creates the relation to tickets on that new entity
- creates the relation to the event id on that new entity (I could have also just retrieved the event from the store state if I wanted to).
Note, this does not feed the datetimes array to the component as that will automatically get updated further upstream.
| </Fragment>; | ||
| } | ||
| return <div>{ getContent() }</div>; | ||
| }; |
There was a problem hiding this comment.
Note the implementation of the isInitializing property (which is actually a state via the withState HOC) that allows for hiding the datetime and ticket lists until the main query is done.
| datetimes: getEntitiesForModel( 'datetime' ), | ||
| tickets: getEntitiesForModel( 'ticket' ), | ||
| }; | ||
| } ), |
There was a problem hiding this comment.
This withSelect HOC takes care of retrieving the datetimes and tickets used for the display but only when isInitializing is false. That way it can confidently use the general selectors once the state is populated by the main query. From that point on any changes to the datetimes or tickets state will immediately get reflected in the rendered component.
| [ 'datetime', datetimeIds, 'tickets' ] | ||
| ); | ||
| setState( { isInitializing: false } ); | ||
| } ), |
There was a problem hiding this comment.
This withSelect HOC is responsible for populating the state with all the datetimes and tickets related to the selected EventId. The state can be populated using the new efficient queries (getRelatedEntitiesForIds).
The sole purpose of this HOC is to populate the state and set the isInitializing local state. isInitializing is then used by the other hocs as a signal for the state being populated and thus other component rendering can occur from whats in the store state.
Once this HOC has populated the state, it effectively is "done", hence the early bail on line 131. Note, this currently does not handle a change in eventId via the input (again just a raw demo). If I was to complete this, I'd have the onEventClick action reset the local isInitializing state and clear the eventespresso/core state of all records from the original event.
9 tasks
nerrad
force-pushed
the
FET/add-relation-type-awareness-to-models-and-stores
branch
from
ab1fe3e to
b4c542b
Compare
nerrad
added a commit
that referenced
this pull request
Mar 5, 2019
## Problem this Pull Request solves As @tn3rb has been working on implementing the CRUD work from the models/data-stores into the REM work he is doing, he's encountering difficulties with: - efficient network queries (so getting all the tickets for all the datetimes attached to an event in as few queries as possible - as opposed to doing a getRelatedTickets request for each datetime). - using the existing selectors for the `eventespress/core` in an expected manner despite the efficient queries. The difficulty lies in the fact that retrieving and setting up all the relations in the store state for entities retrieved through efficient queries is a extensive process that's easy to get "wrong" because of the opinionated way relation data is kept in the state. The purpose of this pull then is to introduce some changes so that: - `BaseEntity` models currently _are aware_ of the possible relations, but are _not_ aware of the relation types. We need to expose this in the models so efficient queries can be built. - Alternatively (and what might be the better option) is `eventespresso/schema` can be used for deriving the relation types and relation models from the schema stored in its state. Then there could simply be selectors that get the needed data for building the appropriate queries and knowing what dispatches to execute to get the correct relations setup in `eventespresso/core`. - `eventespresso/core` will have a selector (and resolver) for getting all the related entities for a collection of entity ids. So for example `getRelatedEntitiesForIds( datetimeIds, 'ticket' )`. This would handle all the necessary dispatches etc for correctly adding the relations to the store state as well as using the new selectors in `eventespresso/schema` to know if relations have to be joined via a join table query. - I'd like to also explore if the schema (and the REST API behaviour) provides enough information to programmatically derive the most efficient endpoint to do the query on. For instance, since the `include` parameter allows for requesting related model entities to be returned in the response, it might be possible to get all the entities and their relations in one go via the join table (or base model). If that is the case, then the number of requests can be reduced more and it might even make the relation dispatches easier. ## Changes in this pull Along with the purpose outlined in the original post, I created a test app in #988 based off of this branch to do some implementation testing of things to ensure it worked as expected. While testing, there were a number of other fixes that had to be done. Along with all the below, unit-tests were updated, new tests added, and additional developer documentation was created as well. ### New features * added `resolveRelationRecordForRelation` action generator (`eventespresso/core`) * added `getRelatedEntitiesForIds` selector and resolver. (`eventespresso/core`) * added new `receiveRelationSchema` action and related reducer to `eventespresso/schema` store. * added new `hasJoinTableRelation` selector and resolver (`eventespresso/schema`). * added new `getRelationType` selector and resolver (`eventespresso/schema`). * added new `getRelationSchema` selector and resolver (`eventespresso/schema`). * added a new `clone` getter to the `BaseEntity` class. Can be used to clone a given entity instance. * added a new `forClone` property to the `BaseEntity` class. Can be used to export a plain object representing all the fields and values on a given entity instance that can immediately be used in instantiating a new entity instance. ### Fixes * Fix incorrect argument list in the `receiveEntityAndResolve` dispatch control invoked in the `createRelation` action. ( `eventespresso/core`) * Add normalization for model and relation names in the `createRelations` action. (`eventespresso/core`) * Ensure the the `getEntityById` and `getRelationEntities` selectors are resolved for the new relations created in the `createRelations` action. (`eventespresso/core`) * add some fixes to the `eventespresso/core` reducer for relations: make sure id is always normalized. * make sure model name is normalized for `getSchemaForModel` resolver in `eventespresso/schema`
eeteamcodebase
pushed a commit
that referenced
this pull request
Mar 5, 2019
…type awareness to models and data stores (#982) ## Problem this Pull Request solves As @tn3rb has been working on implementing the CRUD work from the models/data-stores into the REM work he is doing, he's encountering difficulties with: - efficient network queries (so getting all the tickets for all the datetimes attached to an event in as few queries as possible - as opposed to doing a getRelatedTickets request for each datetime). - using the existing selectors for the `eventespress/core` in an expected manner despite the efficient queries. The difficulty lies in the fact that retrieving and setting up all the relations in the store state for entities retrieved through efficient queries is a extensive process that's easy to get "wrong" because of the opinionated way relation data is kept in the state. The purpose of this pull then is to introduce some changes so that: - `BaseEntity` models currently _are aware_ of the possible relations, but are _not_ aware of the relation types. We need to expose this in the models so efficient queries can be built. - Alternatively (and what might be the better option) is `eventespresso/schema` can be used for deriving the relation types and relation models from the schema stored in its state. Then there could simply be selectors that get the needed data for building the appropriate queries and knowing what dispatches to execute to get the correct relations setup in `eventespresso/core`. - `eventespresso/core` will have a selector (and resolver) for getting all the related entities for a collection of entity ids. So for example `getRelatedEntitiesForIds( datetimeIds, 'ticket' )`. This would handle all the necessary dispatches etc for correctly adding the relations to the store state as well as using the new selectors in `eventespresso/schema` to know if relations have to be joined via a join table query. - I'd like to also explore if the schema (and the REST API behaviour) provides enough information to programmatically derive the most efficient endpoint to do the query on. For instance, since the `include` parameter allows for requesting related model entities to be returned in the response, it might be possible to get all the entities and their relations in one go via the join table (or base model). If that is the case, then the number of requests can be reduced more and it might even make the relation dispatches easier. ## Changes in this pull Along with the purpose outlined in the original post, I created a test app in #988 based off of this branch to do some implementation testing of things to ensure it worked as expected. While testing, there were a number of other fixes that had to be done. Along with all the below, unit-tests were updated, new tests added, and additional developer documentation was created as well. ### New features * added `resolveRelationRecordForRelation` action generator (`eventespresso/core`) * added `getRelatedEntitiesForIds` selector and resolver. (`eventespresso/core`) * added new `receiveRelationSchema` action and related reducer to `eventespresso/schema` store. * added new `hasJoinTableRelation` selector and resolver (`eventespresso/schema`). * added new `getRelationType` selector and resolver (`eventespresso/schema`). * added new `getRelationSchema` selector and resolver (`eventespresso/schema`). * added a new `clone` getter to the `BaseEntity` class. Can be used to clone a given entity instance. * added a new `forClone` property to the `BaseEntity` class. Can be used to export a plain object representing all the fields and values on a given entity instance that can immediately be used in instantiating a new entity instance. ### Fixes * Fix incorrect argument list in the `receiveEntityAndResolve` dispatch control invoked in the `createRelation` action. ( `eventespresso/core`) * Add normalization for model and relation names in the `createRelations` action. (`eventespresso/core`) * Ensure the the `getEntityById` and `getRelationEntities` selectors are resolved for the new relations created in the `createRelations` action. (`eventespresso/core`) * add some fixes to the `eventespresso/core` reducer for relations: make sure id is always normalized. * make sure model name is normalized for `getSchemaForModel` resolver in `eventespresso/schema` "
nerrad
added a commit
that referenced
this pull request
Mar 12, 2019
## Problem this Pull Request solves While working on the demo app (#988) and the Barcode Scanner app (eventespresso/eea-barcode-scanner#7) I realized that there will be need for some sort of reset state action for our stores that allows dispatches to restore state to its default shape. For instance with the barcode scanner app the user might scan a new registration for checkin that we'll want to reset all the tracked related registrations etc in the state. Note: a [pull I did for GB](WordPress/gutenberg#14225) recently that adds more sledgehammer like control over the resolution cache in the `core/data` store. It will make it easier for resetting that state in this pull. The downside is it will be tied to a version of WordPress so I can only use it IF the functions exist.
eeteamcodebase
pushed a commit
that referenced
this pull request
Mar 12, 2019
… state actions to our stores. (#998) ## Problem this Pull Request solves While working on the demo app (#988) and the Barcode Scanner app (eventespresso/eea-barcode-scanner#7) I realized that there will be need for some sort of reset state action for our stores that allows dispatches to restore state to its default shape. For instance with the barcode scanner app the user might scan a new registration for checkin that we'll want to reset all the tracked related registrations etc in the state. Note: a [pull I did for GB](WordPress/gutenberg#14225) recently that adds more sledgehammer like control over the resolution cache in the `core/data` store. It will make it easier for resetting that state in this pull. The downside is it will be tied to a version of WordPress so I can only use it IF the functions exist. "
nerrad
changed the base branch from
FET/add-relation-type-awareness-to-models-and-stores
to
master
|
closing this as it is no longer needed |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
App for demonstrating using the new relation type awareness in the stores.
Very raw, very proof-of-concept.