Fet/demo copy date functionality #988

nerrad · 2019-02-27T20:53:49Z

App for demonstrating using the new relation type awareness in the stores.

Go to WP Data Demo tab in the Event Admin
Enter an Event Id.

Very raw, very proof-of-concept.

…ries

…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.

…dispatch

- returns values of object usable for cloning via a factory.createNew call.

…nto FET/demo-copy-date-functionality

…ries

- fixes a bug with state not updating correctly for entity map.

…dispatch

- returns values of object usable for cloning via a factory.createNew call.

- remove unnecessary prop destruct - remove errant semi-colon

… new relation.

…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.

- 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

Note, this currently does not handle a change in eventId via the input (again just a raw demo). So if you want to test with a different event, currently you need to refresh the page.

nerrad · 2019-03-04T13:20:31Z

assets/src/demo/app.js

+		);
+	}
+	return { onDateClone };
+} )( DatesList );


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.

nerrad · 2019-03-04T13:21:30Z

assets/src/demo/app.js

+			</Fragment>;
+	}
+	return <div>{ getContent() }</div>;
+};


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.

nerrad · 2019-03-04T13:23:14Z

assets/src/demo/app.js

+			datetimes: getEntitiesForModel( 'datetime' ),
+			tickets: getEntitiesForModel( 'ticket' ),
+		};
+	} ),


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.

nerrad · 2019-03-04T13:29:10Z

assets/src/demo/app.js

+			[ 'datetime', datetimeIds, 'tickets' ]
+		);
+		setState( { isInitializing: false } );
+	} ),


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.

@tn3rb

## 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`

@tn3rb

…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` "

## 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.

… 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. "

tn3rb · 2019-05-08T18:53:46Z

closing this as it is no longer needed

nerrad added 18 commits February 25, 2019 20:54

start poc work for complicated model ui

52f8603

started todo so can create pull

22bf8fc

add new selectors/actions etc to schema for relation type related que…

598deec

…ries

add new selector for doing efficient relation entity query

cee6e50

Merge branch 'FET/add-relation-type-awareness-to-models-and-stores' i…

fc0cb69

…nto FET/demo-copy-date-functionality

implement the new selectors and finish off the app

bd4b877

- still needs wired up to an actual view but the app itself should be good to go for testing once that’s done.

add demo app demonstrating cloning of a datetime and updating entitti…

113c68a

…es in the state etc

update build files for changes

07134bf

fix incorrect arg for dispatch

9feb782

ensure entityId is normalized

1ddf200

- fixes a bug with state not updating correctly for entity map.

fix bugs due to incorrectly prepared strings

aeb5d86

make sure we use Immutable.Map and we’re passing the right values on …

133897a

…dispatch

fix bugs with prepped strings used as args

b7cd561

add clone getter to BaseEntity

b3407a3

add forClone getter to BaseEntity

c6c8f01

- returns values of object usable for cloning via a factory.createNew call.

add field extractor for fields and values used for cloning

dc0bb05

Merge branch 'FET/add-relation-type-awareness-to-models-and-stores' i…

3de2213

…nto FET/demo-copy-date-functionality

update build files

67b4c43

nerrad added the category:assets label Feb 27, 2019

nerrad self-assigned this Feb 27, 2019

nerrad added 10 commits March 1, 2019 09:55

started todo so can create pull

0d82915

add new selectors/actions etc to schema for relation type related que…

2b6aa4a

…ries

add new selector for doing efficient relation entity query

f87d64c

fix incorrect arg for dispatch

e734e81

ensure entityId is normalized

9cb2c84

- fixes a bug with state not updating correctly for entity map.

fix bugs due to incorrectly prepared strings

e3b36ab

make sure we use Immutable.Map and we’re passing the right values on …

58574d5

…dispatch

fix bugs with prepped strings used as args

a66d3c7

add clone getter to BaseEntity

1bfd527

add forClone getter to BaseEntity

649f42e

- returns values of object usable for cloning via a factory.createNew call.

nerrad added 9 commits March 1, 2019 14:02

minor fixes

2a80b4d

- remove unnecessary prop destruct - remove errant semi-colon

update build files

850d22d

add missing semiColon

da43bbb

add missing resolving of getRelatedEntities when creating a relation

ed98faa

handle doing reverse resolution of getRelatedEntities when creating a…

d15bb2d

… new relation.

Merge branch 'FET/add-relation-type-awareness-to-models-and-stores' i…

f2c9a73

…nto FET/demo-copy-date-functionality

remove extraneous argument

479af5c

- 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).

use state to track initialization instead of props

cdb9fed

props was flawed becuase its initial value would always be true on re-render instead of retaining the set value via the withSelects.

update build (dev) files

a1cfdb8

nerrad mentioned this pull request Mar 1, 2019

Add join type awareness to models and data stores #982

Merged

10 tasks

nerrad added 8 commits March 1, 2019 15:50

fix another bug and update existing tests for changes

7e6d32d

add jsdocs and unit-test converage

1b64972

add dev docs for new things

92a733d

update tests and fix linting

434b6cc

- tests needed updates due to changes in defaults and fixtures for other tests.

update build files

ab1fe3e

update build files

0a05378

update build files

b455375

nerrad commented Mar 4, 2019

View reviewed changes

nerrad assigned tn3rb Mar 4, 2019

nerrad mentioned this pull request Mar 4, 2019

Add reset state actions to our stores. #998

Merged

9 tasks

nerrad force-pushed the FET/add-relation-type-awareness-to-models-and-stores branch from ab1fe3e to b4c542b Compare March 4, 2019 22:07

nerrad changed the base branch from FET/add-relation-type-awareness-to-models-and-stores to master April 2, 2019 20:59

tn3rb closed this May 8, 2019

tn3rb deleted the FET/demo-copy-date-functionality branch May 8, 2019 18:53

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fet/demo copy date functionality #988

Fet/demo copy date functionality #988

nerrad commented Feb 27, 2019 •

edited

Loading

nerrad left a comment

nerrad Mar 4, 2019

nerrad Mar 4, 2019

nerrad Mar 4, 2019

nerrad Mar 4, 2019

tn3rb commented May 8, 2019

Fet/demo copy date functionality #988

Fet/demo copy date functionality #988

Conversation

nerrad commented Feb 27, 2019 • edited Loading

nerrad left a comment

Choose a reason for hiding this comment

nerrad Mar 4, 2019

Choose a reason for hiding this comment

nerrad Mar 4, 2019

Choose a reason for hiding this comment

nerrad Mar 4, 2019

Choose a reason for hiding this comment

nerrad Mar 4, 2019

Choose a reason for hiding this comment

tn3rb commented May 8, 2019

nerrad commented Feb 27, 2019 •

edited

Loading