Skip to content

Conversation

@tsullivan
Copy link
Member

This re-implements #9011 for 6.0

This PR fixes the navLink generated from a plugin spec object to include the linkToLastSubUrl setting. Without this, the linkToLastSubUrl is always undefined, which by default is treated as if the setting was true

Copy link
Contributor

@cjcenizal cjcenizal left a comment

Choose a reason for hiding this comment

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

Sweet, sweet tests. 🤤 Had a few comments and would like to hear your thoughts!

expect(newApp.id).to.be(spec.id);
});

it('has a built-in default navLink', () => {
Copy link
Contributor

Choose a reason for hiding this comment

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

Such a nit-pick but the term "built-in" isn't necessary here right? 🤓

Copy link
Contributor

Choose a reason for hiding this comment

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

Or in the next two tests.

Copy link
Member Author

Choose a reason for hiding this comment

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

If it's in question, then probably not :)

};
const newApp2 = new UiApp(uiExports, spec2);
expect(newApp2.hidden).to.be(false);
expect(newApp2.listed).to.be(false);
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need all of these assertions here? If one of them fails and the message is "expected true to be false", it will be tricky to figure out what went wrong. If we need all of these assertions, maybe we can split them into two tests, one for "has listed set to true if it's passed as true" and another for "has listed set to false if it's passed as false"?

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 disagree that it is tricky to figure out what went wrong if there is a failure because the failure will have a stack trace that points to the failing assertion. In the past I have went through some hoops to avoid that kind of failure messaging, but eventually just simplified because my team member and myself felt it wasn't worth the extra code.

Copy link
Member

Choose a reason for hiding this comment

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

Doesn't the stack trace solve this issue though? Just trace to the line of the failure.

Copy link
Member Author

Choose a reason for hiding this comment

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

FYI, I'm not exactly sure why Github says this is an outdated change. I didn't explicitly make any change here.

Copy link
Contributor

Choose a reason for hiding this comment

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

That's so funny, I didn't even know about the stack trace. 😄 Yes that addresses my concern.

});
});

describe('hidden and listed flags', () => {
Copy link
Contributor

Choose a reason for hiding this comment

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

When I was reading these tests, I was having a hard time figuring out how these two properties interacted. After I read the source, I saw that listed was dependent on hidden, and that hidden was cast to a boolean values.

I think this structure makes that relationship a little clearer. What do you think?

    describe('hidden', () => {
      describe('is cast to boolean value', () => {
        it('when undefined', () => {
          const spec = {
            id: 'uiapp-test',
          };
          const newApp = new UiApp(uiExports, spec);
          expect(newApp.hidden).to.be(false);
        });

        it('when null', () => {
          const spec = {
            id: 'uiapp-test',
            hidden: null,
          };
          const newApp = new UiApp(uiExports, spec);
          expect(newApp.hidden).to.be(false);
        });
      });
    });

    describe('listed', () => {
      describe('defaults to the opposite value of hidden', () => {
        it(`when it's null and hidden is true`, () => {
          const spec = {
            id: 'uiapp-test',
            hidden: true,
            listed: null,
          };
          const newApp = new UiApp(uiExports, spec);
          expect(newApp.listed).to.be(false);
        });

        it(`dhen it's null and hidden is false`, () => {
          const spec = {
            id: 'uiapp-test',
            hidden: false,
            listed: null,
          };
          const newApp = new UiApp(uiExports, spec);
          expect(newApp.listed).to.be(true);
        });

        it(`when it's undefined and hidden is false`, () => {
          const spec = {
            id: 'uiapp-test',
            hidden: false,
          };
          const newApp = new UiApp(uiExports, spec);
          expect(newApp.listed).to.be(true);
        });

        it(`when it's undefined and hidden is true`, () => {
          const spec = {
            id: 'uiapp-test',
            hidden: true,
          };
          const newApp = new UiApp(uiExports, spec);
          expect(newApp.listed).to.be(false);
        });
      });

      it(`is set to true when it's passed as true`, () => {
        const spec = {
          id: 'uiapp-test',
          listed: true,
        };
        const newApp = new UiApp(uiExports, spec);
        expect(newApp.listed).to.be(true);
      });

      it(`is set to false when it's passed as false`, () => {
        const spec = {
          id: 'uiapp-test',
          listed: false,
        };
        const newApp = new UiApp(uiExports, spec);
        expect(newApp.listed).to.be(false);
      });
    });

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 was also a little surprised that these properties have a relationship and the logic previously had no test coverage. But I think if it is hard to figure that out just by looking at the test, would it suffice to just add a comment in the code that all these tests are here to check the logic for the relationship?

Your proposal looks good to me though, and I appreciate you taking the time to present it like that. I have no problem with integrating it. I'll add a comment as well.

@cjcenizal
Copy link
Contributor

Really weird test failure!

Copy link
Member

@pickypg pickypg left a comment

Choose a reason for hiding this comment

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

LGTM once tests pass!

Copy link
Contributor

@cjcenizal cjcenizal left a comment

Choose a reason for hiding this comment

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

LGTM!

@tsullivan tsullivan force-pushed the fix/ui-app-linkToLastUrl-ii branch from c17bf54 to 25070cf Compare July 21, 2017 22:45
@tsullivan tsullivan merged commit 7d08c68 into elastic:master Jul 21, 2017
@tsullivan tsullivan deleted the fix/ui-app-linkToLastUrl-ii branch July 21, 2017 23:34
@tsullivan tsullivan changed the title Fix/ui app link to last url ii Allow plugin app to specify linkToLastUrl Jul 21, 2017
@tsullivan tsullivan added the Team:Core Platform Core services: plugins, logging, config, saved objects, http, ES client, i18n, etc t// label Jul 21, 2017
@tsullivan tsullivan changed the title Allow plugin app to specify linkToLastUrl Allow plugins to turn off the “link to last URL” navigation helper Jul 21, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

release_note:enhancement review Team:Core Platform Core services: plugins, logging, config, saved objects, http, ES client, i18n, etc t// v6.0.0-rc1 v6.0.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants