Components: Deprecate `withContext` HOC and remove its usage #8189

gziolo · 2018-07-25T10:27:33Z

Description

It's part of our efforts to stablize API.

How has this been tested?

npm test

Checklist:

My code is tested.
My code follows the WordPress code style.
My code follows the accessibility standards.
My code has proper inline documentation.

gziolo · 2018-07-25T10:29:34Z

packages/element/src/serialize.js

@@ -445,6 +445,8 @@ export function renderElement( element, context = {} ) {
 				},
 				context
 			);
+		default:
+			throw new Error( tagName );


I couldn' make it throw so I figured out we don't use the source code in all cases. It turned out it is even worse, we don't use in a majority of cases. I opened #8188 to fix it before I can continue debugging.

packages/components/src/higher-order/with-context/index.js

gziolo · 2018-08-06T10:13:20Z

packages/element/src/test/serialize.js

+					</Consumer>
+				</Provider>
+				{ '|' }
+				<Consumer>


It fails here because the mutation present in here: https://github.com/WordPress/gutenberg/pull/8189/files#diff-a72c42fcaf462e92ab6cd7a52680df76R472

it's no longer an issue.

gziolo · 2018-08-06T10:20:56Z

Almost there, I made all the tests pass, which is very promising. When comparing the current implementation with react-dom I came up with a conclusion that it will fail when there are multiple providers used. I added a unit test which indeed fails. It might be a more complex refactor though. Any ideas how to fix it with the minimal amount of work? 😄

gziolo · 2018-08-09T13:55:16Z

I took advantage of the fact we use recursion and add another param which transports values from the providers created with new Context API: 88e833c

It needs some polishing but it solves all the issues we had.

aduth · 2018-08-09T14:51:37Z

packages/blocks/src/block-content-provider/index.js

-BlockContentProvider.childContextTypes = {
-	BlockContent: () => {},
+	return (
+		<Provider value={ { BlockContent } }>


We pass a new value each render. I suppose this isn't a huge issue since it's used only in the serialization step anyways, but why does the context need to be an object anyways? Why not just the BlockContent value directly?

aduth · 2018-08-09T14:52:30Z

packages/blocks/src/block-content-provider/index.js

+ *
+ * @return {Component} Enhanced component with injected context as props.
+ */
+export const withBlockContentContext = ( mapContextToProps ) => createHigherOrderComponent( ( OriginalComponent ) => {


To my previous point, I don't see why we'd be passing anything other than the content component. We shouldn't need to map anything.

I did it for consistency with other context related HOCs. However, you made a good point. I will refactor as suggested.

aduth · 2018-08-09T15:34:29Z

packages/blocks/src/block-content-provider/index.js


 /**
 * Internal dependencies
 */
 import { serialize } from '../api';

+const { Consumer, Provider } = createContext( {


I think this still needs to be updated to not set the initial context as an object, but rather the noop directly.

Right, missed this one :(

aduth · 2018-08-09T15:35:24Z

packages/blocks/src/block-content-provider/index.js

 /**
 * An internal block component used in block content serialization to inject
 * nested block content within the `save` implementation of the ancestor
 * component in which it is nested. The component provides a pre-bound
 * `BlockContent` component via context, which is used by the developer-facing
 * `InnerBlocks.Content` component to render block content.
 *
+ * @return {WPElement} Element with BlockContent injected via context.


Minor: We might want to establish conventions around tag order. How I've treated it, I always have @return last, preceded by @param, preceded by anything else.

Yes, makes sense. In general, we could make JSDoc validation more strict since we started using it more consistently.

…ders

gziolo · 2018-08-13T07:23:00Z

I pushed two more commits:

fix for the issues raised with the recent review iteration (b6b7da7)
one more tests which ensures we can properly serialize nested providers (e32503e)

aduth · 2018-08-13T13:28:50Z

packages/components/src/higher-order/with-context/test/index.js

@@ -39,6 +39,7 @@ describe( 'withContext', () => {
 		);

 		expect( wrapper.root.findByType( 'div' ).children[ 0 ] ).toBe( 'ok' );
+		expect( console ).toHaveWarned();


Minor: Question came up from @danielbachhuber about testing with deprecated warnings, and potential for conflicts with its internal memoization. Made me think over the weekend that the fact we test against console logging is a bit of an abstraction piercing; while it seems obvious deprecated would log to console by its description, we can't know for certain, and seems we should test that deprecated was merely called, regardless of its internal implementation.

I'd like to think this would be as simple as? ...

const deprecated = jest.mock( '@wordpress/deprecated' ); // ... expect( deprecated ).toHaveBeenCalled();

I think it should need:

import deprecated from '@wordpress/deprecated'; jest.mock( '@wordpress/deprecated', () => jest.fn() ); expect( deprecated ).toHaveBeenCalled();

I can give it a try.

Related docs: https://jestjs.io/docs/en/mock-functions#mocking-modules

Refactored in cf41540.

gziolo added [Type] Breaking Change For PRs that introduce a change that will break existing functionality [Package] Components /packages/components labels Jul 25, 2018

gziolo self-assigned this Jul 25, 2018

gziolo requested a review from aduth July 25, 2018 10:27

gziolo commented Jul 25, 2018

View reviewed changes

gziolo added the [Status] In Progress Tracking issues with work in progress label Jul 25, 2018

gziolo mentioned this pull request Jul 25, 2018

Tests: Improve configuration and mocking strategy #8188

Merged

4 tasks

gziolo force-pushed the update/deprecate-with-context branch from 76b5cdc to 12793b1 Compare August 6, 2018 10:10

gziolo commented Aug 6, 2018

View reviewed changes

packages/components/src/higher-order/with-context/index.js Outdated Show resolved Hide resolved

gziolo commented Aug 6, 2018

View reviewed changes

gziolo requested a review from youknowriad August 6, 2018 10:18

This was referenced Aug 6, 2018

Add components examples in README.md files - Part 2 #8338

Merged

Context API support akxcv/vuera#50

Open

gziolo force-pushed the update/deprecate-with-context branch from 12793b1 to 88e833c Compare August 9, 2018 13:51

gziolo removed the [Status] In Progress Tracking issues with work in progress label Aug 9, 2018

gziolo requested a review from a team August 9, 2018 14:41

gziolo added this to the 3.6 milestone Aug 9, 2018

aduth requested changes Aug 9, 2018

View reviewed changes

gziolo force-pushed the update/deprecate-with-context branch from 8ef02fb to fc4997d Compare August 9, 2018 15:09

aduth requested changes Aug 9, 2018

View reviewed changes

aduth reviewed Aug 9, 2018

View reviewed changes

gziolo added 6 commits August 13, 2018 09:06

Components: Deprecate withContext HOC

568e23e

Element: Add support for Context API in serializer

4f071be

Element: Make serializer work with nested context consumers and provi…

a46b6c5

…ders

Element: Improve detection for Context API components

e42aaa8

Components: Update deprecation version for wp.component.withContext

00ca6ec

Blocks: Simplify BlockContent context HOC implementation

69edd56

Blocks: Addressing feedback from review

b6b7da7

gziolo force-pushed the update/deprecate-with-context branch from fc4997d to b6b7da7 Compare August 13, 2018 07:13

Element: Add test for serialization with nested providers

e32503e

Test: Fix test description in serializer test suite

3141227

aduth approved these changes Aug 13, 2018

View reviewed changes

Tests: Mock deprecated when testing if it was called

cf41540

gziolo merged commit ca39dc5 into master Aug 14, 2018

gziolo deleted the update/deprecate-with-context branch August 14, 2018 04:48

This was referenced Aug 15, 2018

Fix our custom element serializer in IE11 #8967

Merged

WIP: Feature: Implement forwardRef in wp.element.createHigherOrderComponent #7557

Closed

aduth mentioned this pull request Mar 25, 2020

Element: Fix serializer handling of multiple distinct contexts #21156

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Components: Deprecate `withContext` HOC and remove its usage #8189

Components: Deprecate `withContext` HOC and remove its usage #8189

gziolo commented Jul 25, 2018 •

edited

Loading

gziolo Jul 25, 2018

gziolo Aug 6, 2018

gziolo Aug 13, 2018

gziolo commented Aug 6, 2018 •

edited

Loading

gziolo commented Aug 9, 2018

aduth Aug 9, 2018

aduth Aug 9, 2018

gziolo Aug 9, 2018

aduth Aug 9, 2018

gziolo Aug 9, 2018

aduth Aug 9, 2018

gziolo Aug 13, 2018

gziolo commented Aug 13, 2018

aduth Aug 13, 2018

gziolo Aug 14, 2018

gziolo Aug 14, 2018

gziolo Aug 14, 2018

Components: Deprecate withContext HOC and remove its usage #8189

Components: Deprecate withContext HOC and remove its usage #8189

Conversation

gziolo commented Jul 25, 2018 • edited Loading

Description

How has this been tested?

Checklist:

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gziolo commented Aug 6, 2018 • edited Loading

gziolo commented Aug 9, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gziolo commented Aug 13, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Components: Deprecate `withContext` HOC and remove its usage #8189

Components: Deprecate `withContext` HOC and remove its usage #8189

gziolo commented Jul 25, 2018 •

edited

Loading

gziolo commented Aug 6, 2018 •

edited

Loading