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.

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

[Glimmer2] Move escape tests to ember-glimmer #13143

Closed
wants to merge 1 commit into from

Conversation

code0100fun
Copy link
Contributor

Moved to content tests.

  • Convert capitalized path deprecation test
  • Convert null object properties test
  • Add trusted curlies moduleFor (works with TextNode ignore in assertInvariants)
  • HTML content in non-escaped curlies
  • HTML content in escaped curlies
  • Test all escapes of matrix values

@@ -73,6 +73,8 @@ class DynamicContentTest extends RenderingTest {
['@test it can render a dynamic path']() {
this.renderPath('message', { message: 'hello' });

expectNoDeprecation();
Copy link
Contributor Author

Choose a reason for hiding this comment

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

To cover this test. Not sure if this is necessary anymore. Looks like its the last piece related to deprecated global lookup (86fa0ab)?

Copy link
Member

Choose a reason for hiding this comment

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

Actually, the that test is testing that when you do {{CaptializedPath}}, and that you have a CaptializedPath property on the object, it does not emit a deprecation warning. Can you add this test back? (And remove this expectNoDeprecation)

@code0100fun code0100fun force-pushed the glimmer-escape-tests branch from 64e7589 to c8a0e64 Compare March 20, 2016 23:22
@code0100fun code0100fun changed the title [Glimmer2] Move escape tests to ember-glimmer WIP [Glimmer2] Move escape tests to ember-glimmer Mar 20, 2016
@code0100fun code0100fun force-pushed the glimmer-escape-tests branch from c8a0e64 to c4fae53 Compare March 20, 2016 23:53
equal(view.$().text(), '2');
});

QUnit.test('should read from an Object.create(null)', function() {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not sure if this is now covered by these changes from c655638, @chancancode?

Copy link
Member

Choose a reason for hiding this comment

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

I think that test is slightly different: the test I added was for {{nullObject}} (which apparently does not work in htmlbars :P), whereas this is testing {{nullObject.foo}} works. So it seems fine to keep both!

@code0100fun code0100fun force-pushed the glimmer-escape-tests branch 3 times, most recently from fb8e091 to aa0b832 Compare March 22, 2016 12:43
}
});

QUnit.test('should read from a global-ish simple local path without deprecation', function() {
Copy link
Member

Choose a reason for hiding this comment

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

@chancancode
Copy link
Member

I think most of these tests can be "matrix tested" by adding a new module:

moduleFor('Dynamic content tests ("trusted" curlies)', class extends DynamicContentTest {

  renderPath(path, context = {}) {
    this.render(`{{{${path}}}`, context);
  }

});

This would run all the shared tests cases against {{{foo}}}, following the I-N-U-R pattern as appropriate. You can then add more methods in this class to test extra stuff not covered by the shared cases.

@@ -59,6 +59,102 @@ moduleFor('Static content tests', class extends RenderingTest {

});

moduleFor('Null object tests', class extends RenderingTest {
['@test it should read from an Object.create(null)']() {
Copy link
Member

Choose a reason for hiding this comment

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

This could probably go into the shared DynamicContentTest to test against all the possible positions. Something like:

  ['@test it can read from a null object']() {
    let nullObject = Object.create(null);
    nullObject['message'] = 'hello';

    this.renderPath('nullObject.message', { nullObject });

    this.assertText('hello');

    this.assertStableRerender();

    this.runTask(() => set(nullObject, 'message', 'goodbye'));

    this.assertText('goodbye');
    this.assertInvariants();

    nullObject = Object.create(null);
    nullObject['message'] = 'hello';

    this.runTask(() => set(this.context, 'nullObject', nullObject));

    this.assertText('hello');
    this.assertInvariants();
  }

@homu
Copy link
Contributor

homu commented Mar 27, 2016

☔ The latest upstream changes (presumably #13190) made this pull request unmergeable. Please resolve the merge conflicts.

@code0100fun code0100fun force-pushed the glimmer-escape-tests branch 2 times, most recently from 0c59b0b to 6016ed1 Compare March 27, 2016 20:56
this.assertSameNode(newSnapshot[i], oldSnapshot[i]);
if (!(newSnapshot[i] instanceof TextNode && oldSnapshot[i] instanceof TextNode)) {
this.assertSameNode(newSnapshot[i], oldSnapshot[i]);
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

It looks like escaped content creates a new node instead of updating the node value. This happens in htmlbars and glimmer. Not sure if this is intended or expected behavior or a bug. For now this is how I have made the assertInvariants pass for escaped text content.

Copy link
Member

Choose a reason for hiding this comment

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

I think this is fine for now as long as we clean it up before merge. I'll try to come up a suggestion. I have a few ideas, but I need to look into the details to know if they would work.

As for your question, this is expected. The content inside a triple curlies are parsed and populated by the browser. If the source string changes, we have to wipe out the existing nodes and have the browser re-create them. So this is currently just a definciency in the test abstraction, not a bug in the implementation.

@code0100fun code0100fun force-pushed the glimmer-escape-tests branch 4 times, most recently from f45a4e9 to 0a736f2 Compare April 3, 2016 05:26
@code0100fun code0100fun changed the title WIP [Glimmer2] Move escape tests to ember-glimmer [Glimmer2] Move escape tests to ember-glimmer Apr 3, 2016
@code0100fun code0100fun force-pushed the glimmer-escape-tests branch from 3d4652f to aa12b52 Compare April 4, 2016 02:04
@@ -244,6 +340,14 @@ moduleFor('Dynamic content tests (content position)', class extends DynamicConte

});

moduleFor('@htmlbars Dynamic content tests ("trusted" curlies)', class extends DynamicContentTest {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

These tests are currently failing on IE9/10/11. Tagged them for HTMLBars for now.

@code0100fun
Copy link
Contributor Author

I couldn't figure out a clean way to integrate the escaped HTML tests into the test matrix.

All the existing values in the matrix are tested in {{{triple curlies}}} but there are some glimmer failures on IE.

I left explicit tests of HTML content mainly because assertInvariants was causing issues with HTML content and I don't have a clear understanding of how to refactor the test runner to account for these changes.

@chancancode, hopefully this is close to acceptable. Sorry you've had to sink so much time on this 😅

@chancancode
Copy link
Member

Thank you for your work on this! I'll take a look tomorrow!

wycats pushed a commit that referenced this pull request Apr 5, 2016
[Glimmer2] Move escape tests to `ember-glimmer`
@chancancode
Copy link
Member

@code0100fun Thank you again for your work, I merged this in #13259. This turned out to be a bit more difficult to abstract than I expected, because it's testing something pretty low-level. HTMLBars tend to have more "marker" elements than Glimmer (empty text nodes, etc), but I think I have found an okay path. It's still not as nice as I wanted it to be, but it's good enough for now! (You can see the result in #13259.)

If you or other people have better ideas for those abstractions, feel free to open subsequent PRs to improve it.

@chancancode chancancode closed this Apr 5, 2016
@code0100fun code0100fun deleted the glimmer-escape-tests branch April 6, 2016 00:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants