Gutenberg Integration Main Feature Branch #331
Merged
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
This was referenced Apr 24, 2018
Closed
# Conflicts: # assets/dist/build-manifest.json # assets/dist/ee-manifest.84871ecdc22c246e9b73.dist.js # assets/dist/ee-reactVendor.7eaf96fc28e4d8e911cd.dist.js
# Conflicts: # package-lock.json
) * Configure wp global so its aliased to external packages in webpack This allows us to import the services as packages rather than access the global directly in our builds. This helps future proof things - should WordPress publish any of these services as actual npm packages, we can just import them directly and then modify the webpack config, avoiding the necessity to go through all our files and modify them there.
* Remove empty index.js and add .gitignore This commit still preserves folder structure via the use of `.gitignore` files. * Remove empty javascript file from build config
* Add helper to get collection route index and expose for js via eejs.data * First pass of js side of things for the list wp.data implementation `src/data/model/endpoints` expose: - `getEndpoint` (default) for getting the endpoint for a model name (via the server side generated endpoints array exposed on the `eejs.data` global. - `endpoints` : the full endpoints array. - `applyQueryString`: which receives a model name and a query string and applies the query string to the endpoint corresponding to that model name and returns the final assembled endpoint. `src/data/ee-lists/…` - selectors for entities attached to a specified model and cached by query string - reducers for updating the store state for lists cached by query string - resolvers for the initial api query to retrieve entities matching the query string - actions describing the various actions that can be dispatched to update the store state. * Add mock for `@wordpress/api-request.js` to use for tests * Add more dependencies and update config - adds babel plugin transform for async generator functions. - adds core-js library (used with jest tests for async generaotr related tests). * Fix lint errors * Install new dev dependency “deep-freeze” is an implementation of the Object.freeze javascript spec. This is used in various js unit-tests to preserve an object is not mutated and not interacted with in various assertions (especially in redux like code where state is not mutated but preserved across history) * Finish js unit tests and apply fixes exposed from unit tests * Just return endpoint (not full url) from collection routes index method * Add a named resolver for matching the named selector, getEvents * Add selector for checking events requesting state * Install gutenberg as a devDependeny The goal here is to be able to do jest tests for things requiring gutenberg dependencies. * Add initial test for EventSelect component This was a fun one to do because I basically had to figure out how I could load in gutenberg components that were composed in the component I wanted to test! * Add more tests for the eventselector component
<!-- Thanks for your pull request. Comments within these type of tags will be hidden and not show up when you submit your pull request --> <!-- Please answer the following questions in order to expediate acceptance --> ## Problem this Pull Request solves <!-- Please describe your changes in the context of the problem they solve --> The file `assets/src/data/model/validators.js` contained a bunch of methods that used the term `validate` when in fact its more accurate to use the term `assert` being that the methods could potentially throw an error when validation fails. In keeping with the convention used elsewhere I chose to change the name of these methods (along with the file name). ## How has this been tested <!-- Please describe in detail how you tested your changes and how testing can be reproduced --> <!-- Include details of your testing environment, and tests ran to see how your changes affect other areas of code --> <!-- Include any notes about automated tests you've written for this pull request. Pull requests with automated tests are preferred. --> * [x] verified that existing unit-tests pass.
# Conflicts: # core/domain/services/assets/CoreAssetManager.php # package-lock.json
Currently there is need for a lot of boilerplate code to handle any components utilizing response data from our REST endpoints related to models. It would help to reduce a lot of boilerplate if instead of passing around the response objects, properly constructed model entity instances are passes around instead. Any type checking is thus much simpler and it makes for more straight-forward usage of model data in components. ### Current Targets * [x] Create a model entity constructor factory that allows for lazy loading of a model entity constructor used to construct model entity instances. * [x] Within the factory when a model entity constructor is created, it will hit the schema endpoint for the given model name and use that to define the validation property in the created constructor. * [x] Created constructors will be cached so we only ever have to hit that model schema endpoint once. * [x] Rewire the existing stores so instead of using generic objects from the rest response, we're using the model entities instances. * [x] Currently, there is one model that does not have primary keys (`Term_Relationship`) and the js entity/repository/store work does not account for models that may not have primary keys. This is something that will have to be thought through regarding how we handle this. Possibly done as a part of this pull or a separate pull. We may be able to do it server side (i.e. provide a "computed" primary key) so client code doesn't have to go through gymnastics to account for primary keyless models. ### EventAttendeesBlock Since the work in here affects the attendees shortcode block (our first block) I'm going to work on refining the block as well in this branch to get it ship ready. * [x] Make any necessary changes for block (or related code) to use new model-entities * [x] Allow for expired entities by default * [x] Add some editor only error notice for when there's an issue. * [x] Don't pass attributes for server side render that are set to 0. This causes the shortcode parser to behave differently than the native shortcode defaults. * [x] Only show ticket/datetime selectors when the necessary id is available. * [x] Ensure any selected Event/DateTime/Ticket persists in the inspector settings for that block. * [x] Order entities in selectors by date descending. * [x] ~If there are no events selected and there would be a default active event used for the ServerSideRender, make sure that active event is pre-selected in the selector. This one will be a bit trickier to do because I'm not sure how the block will receive communication that there is an active event in time to set that on the selector... I might have to pre-set the attributes based on that.~ I simply could not do this because of the way `ServerSideRender` works. Instead what I've done is added a notice when a default list of attendees is provided by SSR. The alternative is to have anything shown on initial block setup and just have a placeholder. * [x] ~ Fix the limit for attendees not working. ~ it actually works, its just kind of laggy because of the nature for how SSR works. The ultimate fix will be not using SSR! ### Dependencies We also discussed in slack the necessity to have the rest response for models include any direct foreign key references on the model. For instance, currently, datetimes are not returned in the rest response with a `EVT_ID` field even though that is a field on the model server side. See #636 ## How has this been tested * [x] passing unit tests (new/updated/existing) * [x] EventAttendees block usage.
* split out configuration between editor and frontend * don’t assume same default dependencies for frontend scripts * add placeholder for frontend script/style builds
* move validators and other utils into helpers and new validators export * configure eejs.validators export and ensure its loaded * update build files * update docs
* make sure status label is localized for select * update build files (dev) * update snapshot due to component change
…l default object on the array (#760) * adjust test to show bug * fix linting * ensure only arrays are merged. * update build files (dev) * update build files
… 5.0 (#759) * remove wp vendor assets from build config - no longer building react, react-dom, lodash into our own vendor script - set react, react-dom, lodash globals as externals * fix failing test due to enzyme mount incompatibility with package updates * copy in vendor dist files from WP core - we’ll keep these updated from wp core whenever core updates them. * add wp shim and move wp shim loading early in EE bootstrap * add conditional loading for bundled vendor libraries - only loading vendor scripts if they aren’t available in the current WordPress environment. * update all build files (dev) * more package fixes/updates * linting mods * update build file changes * remove unnecessary VendorJavascriptAsset * update build files (dev)
PHPStorm doesn't provide code assistance for any imports we use in our js modules that are configured in webpack to point to externals. For example in webpack, `@eventespresso/components` points to `eejs.components`. This means that whenever we use something like this in our modules, PhpStorm doesn't know how to resolve it and thus we don't get things like code completion etc for that import:
```
import { isSchema } from '@eventespresso/validators';
```
This pull fixes that by exposing a special `phpstorm-webpack.config.js` file that is not used in any builds, but configured specifically to help PHPStorm with resolving aliased imports.
Included documentation in the commit provides instructions on how to implement.
## Problem this Pull Request solves For context see [this grinder post](http://p2.eventespresso.com/2018/10/22/gutenberg-side-effect-extensibility-of-ee/) In this pull the `<EventAttendees />` block will be converted so that: - it does not transform a shortcode to the block (we'll leave shortcodes as their own thing). - it does not use SSR for rendering the content in the editor. Instead the editor will have its own component for displaying the data. Styles for the content in the editor will be also loaded on the frontend. - explore using react to lazy load the content on the frontend as well, however, in the interest of time we may still have the same template generated and loaded on the frontend as what is done in the client side in the editor. So there still would be a consistent rendering. IF there's time, we could offer the option to toggle between lazy loading and SSR on the frontend (which might be a good thing for events with a lot of attendees). ## Other things that are implemented in this pull: * Organized panels for different options * New Gravatar controls for controlling the size of the gravatar. * Add more css classes to containers. One change here is that every Event Espresso block receives the `event-espresso-blocks` css class and every *core* block receives the `ee-core-blocks` class. One potential use-case for this is when troubleshooting client sites, the support agent can just use a user-agent style sheet that highlights all our blocks with a border in content (so they readily standout). Another use-case is searching the page source when troubleshooting. Another potential use-case will be for maintaining certain common style guides for all our blocks that can be applied using css specificity rules. * Every request for attendees pulls gravatar images by default but only SHOWS the gravatar in the editor preview if `showGravatar` is true, this saves a round trip. * Every attendees request pulls a limit of 100 attendees regardless of the set limit. This resolves the "known issue" noted before. The limit control simply affects how many attendees are displayed in the preview. * Bunch of user context messaging added. For example, on the initial block insertion, the user is instructed to select an event to get started. Thus the _default_ behaviour of the block is to NOT show any attendees (differs from shortcode in that there is default query).
The `EventAttendees` block is the first integration of EE with Gutenberg. Along with adding this block to EE core, this pull also: - expands the new javascript build process. - adds a GB block framework in php for registering blocks and block assets. - adds a new javascript framework for not only GB blocks, but also doing react work in general (components, model entities etc).
…resso-core into Gutenberg/master
nerrad
changed the title
eeteamcodebase
pushed a commit
that referenced
this pull request
Nov 9, 2018
… 1 of the new WordPress editor and blocks system integration (#331) This is the initial Gutenberg integration merge for EE. Bringing: - A new `EventAttendees` block for use in the new WordPress editor (codename Gutenberg) - expands the new javascript build process. - adds a block framework in php for registering blocks and block assets. - adds a new javascript framework for not only blocks, but also doing react work in general (components, model entities etc). - expands on javascript documentation for the new things. The integration will only be _active_ when the new editor/block system is present in the WordPress environment."
10 tasks
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.
This pull request is for the initial Gutenberg integration work we are doing.
Purpose
The work in this branch has the following purposes:
Once we get to a point where we have working EE core shortcodes for Gutenberg we can prepare testing steps and prep for merge into master.
Refactoring of the EE CPT route editors (events, venues, attendee) will happen after this branch has been merged to master.
Workflow