Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Element: Fix serializer handling of multiple distinct contexts #21156

Closed
wants to merge 6 commits into from
Closed

Element: Fix serializer handling of multiple distinct contexts #21156

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
6313fad
Element: Fix serializer handling of multiple distinct contexts
aduth Mar 25, 2020
90dacf0
Element: Add non-mixed test case for nested context
aduth Mar 26, 2020
014e884
Element: Add testt case for rendering Context directly
aduth Mar 26, 2020
947a58f
Element: Guard property access to context consumer `_context`
aduth Mar 26, 2020
c64b80a
Try common Map implementation
aduth Mar 26, 2020
621789b
Try avoiding explicit argument to constructor
aduth Mar 26, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions package-lock.json
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

2 changes: 1 addition & 1 deletion packages/element/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -313,7 +313,7 @@ Serializes a React element to string.
_Parameters_

- _element_ `WPElement`: Element to serialize.
- _context_ `?Object`: Context object.
- _context_ `[Map]`: Context object.
- _legacyContext_ `?Object`: Legacy context object.

_Returns_
Expand Down
1 change: 1 addition & 0 deletions packages/element/package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,6 +25,7 @@
"dependencies": {
"@babel/runtime": "^7.8.3",
"@wordpress/escape-html": "file:../escape-html",
"core-js-pure": "^3.6.4",
"lodash": "^4.17.15",
"react": "^16.9.0",
"react-dom": "^16.9.0"
Expand Down
14 changes: 11 additions & 3 deletions packages/element/src/serialize.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -36,6 +36,7 @@ import {
kebabCase,
isPlainObject,
} from 'lodash';
import CoreJSMap from 'core-js-pure/features/map';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason why we use this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's meant to be temporary, an experiment to see if it would fix the previously-observed issue to use a very predictable implementation.


/**
* WordPress dependencies
Expand Down Expand Up @@ -347,7 +348,7 @@ function getNormalStylePropertyValue( property, value ) {
* Serializes a React element to string.
*
* @param {WPElement} element Element to serialize.
* @param {?Object} context Context object.
* @param {Map=} context Context object.
* @param {?Object} legacyContext Legacy context object.
*
* @return {string} Serialized element.
Expand Down Expand Up @@ -411,11 +412,18 @@ export function renderElement( element, context, legacyContext = {} ) {

switch ( type && type.$$typeof ) {
case Provider.$$typeof:
return renderChildren( props.children, props.value, legacyContext );
context = context ? new CoreJSMap( context ) : new CoreJSMap();
context.set( type, props.value );
return renderChildren( props.children, context, legacyContext );

case Consumer.$$typeof:
return renderElement(
props.children( context || type._currentValue ),
props.children(
( context &&
type._context &&
context.get( type._context.Provider ) ) ||
type._currentValue
),
context,
legacyContext
);
Expand Down
69 changes: 69 additions & 0 deletions packages/element/src/test/serialize.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -317,6 +317,75 @@ describe( 'renderElement()', () => {
expect( result ).toBe( 'inner provided|outer provided' );
} );

it( 'renders Context gracefully', () => {
const Context = createContext( 'Default' );

const result = renderElement(
<Context>{ ( value ) => value }</Context>
);

expect( result ).toBe( 'Default' );
} );

it( 'renders proper value through Context API when nested, distinct providers present', () => {
const {
Consumer: FirstConsumer,
Provider: FirstProvider,
} = createContext();
const {
Consumer: SecondConsumer,
Provider: SecondProvider,
} = createContext();

const result = renderElement(
<FirstProvider value="First">
<FirstConsumer>
{ ( first ) => (
<SecondProvider value="Second">
<SecondConsumer>
{ ( second ) =>
`First: ${ first }, Second: ${ second }`
}
</SecondConsumer>
</SecondProvider>
) }
</FirstConsumer>
</FirstProvider>
);

expect( result ).toBe( 'First: First, Second: Second' );
} );

it( 'renders proper value through Context API when nested, distinct providers present (mixed order)', () => {
const {
Consumer: FirstConsumer,
Provider: FirstProvider,
} = createContext();
const {
Consumer: SecondConsumer,
Provider: SecondProvider,
} = createContext();

const result = renderElement(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that e2e tests fail for blocks that have nesting. I'm wondering if there should be another unit tests that replicate how InnerBlocks works, if I follow it properly it would be something like:

<FirstProvider value="First">
 	<FirstConsumer>
 		{ ( first ) => (
 			<SecondProvider value="Second">
 				<SecondConsumer>
 					{ ( second ) => `First: { first }, Second: ${ second }` }
 				</SecondConsumer>
			</SecondProvider>
 		) }
	</FirstConsumer>
</FirstProvider>

Although, I don't see any reason why it would make any difference.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not really sure what's going on with the end-to-end tests, to be honest. I've not been able to reproduce those same failures in my local environment.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a test case for this in 90dacf0 for good measure. It passes, as expected. Still struggling with the end-to-end tests in Travis.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've just realized that we use one shared context for InnerBlocks so the following might be closer to the use case that fails on Travis:

<Provider value="outer">
 	<Consumer>
 		{ ( outter ) => (
 			< Provider value="inner">
 				<Consumer>
 					{ ( inner ) => `Outer: { outer }, Inner: ${ inner }` }
 				</Consumer>
			</Provider>
 		) }
	</Consumer>
</Provider>

I don't think it's much different from a similar existing test though. I can't think of any reason why it fails on Travis :(

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh no :(

<FirstProvider value="First">
<SecondProvider value="Second">
<FirstConsumer>
{ ( first ) => (
<>
First: { first }, Second:{ ' ' }
<SecondConsumer>
{ ( second ) => second }
</SecondConsumer>
</>
) }
</FirstConsumer>
</SecondProvider>
</FirstProvider>
);

expect( result ).toBe( 'First: First, Second: Second' );
} );

it( 'renders RawHTML as its unescaped children', () => {
const result = renderElement( <RawHTML>{ '<img/>' }</RawHTML> );

Expand Down