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

Consider string as a scope #408

Open
ro0gr opened this issue May 28, 2018 · 2 comments
Open

Consider string as a scope #408

ro0gr opened this issue May 28, 2018 · 2 comments
Labels

Comments

@ro0gr
Copy link
Collaborator

ro0gr commented May 28, 2018

This is a feature request to slightly improve ergonomic of the Page Object Components definition.

Currently the shortest form of a component definition would look something like:

{
  someField: {
    scope: 'some-field-selector'
  }
}

When I define few components on a page object it gets a bit noisy because we need to define an object with a scope option to create a component. For me the most used building blocks of the Page Object are Components. I think it's great to have a shorthand syntax for component definitions like we do have for collections, e.g collection('items-selector').

I propose to consider all the string values of a page object definition as a component selectors, so the minimal syntax to define a page object would look something like:

create({
  header: 'header',
  body: 'article',
  header: 'footer',  
  signOut: '[data-test-logout]',
  breadcrumbs: collection('[date-test-breadcrumb]')
});

This change might break some existing page objects but honestly I can't imagine a use case for the need to store string values in the page object definition 🤔 Probably the feature (if)should be included in v2.

Would appreciate any thoughts.

@ro0gr ro0gr added the feature label May 28, 2018
@ro0gr
Copy link
Collaborator Author

ro0gr commented Jun 21, 2018

While the proposal feels ergonomic to me, unfortunately it's not a forward compatible change.

If we accept the proposal then on the page object creation phase we need to guard if a found string is neither a scope nor a testContainer. If we decide to extend component definitions with a new string options we would break consumers of the older ember-cli-page-object versions.

@ro0gr ro0gr closed this as completed Jun 21, 2018
@ro0gr
Copy link
Collaborator Author

ro0gr commented Jan 12, 2020

After thinking about it more, I think we can achieve this.

For now, we support 2 string properies on a page object definition. So in order achieve string scopes, we now have to guard if the key is not equal to scope or testContainer. In case if want to add some new string key to public API, things get even worse.

I believe there is no any point to store on a definition any strings other than DOM query related. So probably we can isolate all of such props under some conventional key, and dissalow any strings other than scope:

const definition = {
  // shorthand to describe "withAStringScope" component with a ".scope" scope
  withAStringScope: '.scope',

  // classic withAScope component with a ".scope" scope
  withAScope: {
    scope: '.scope'
  },

  compWithAComplexQuery: {
     // any props contributing to the final CSS selector should be placed in ther
    scope { // maybe "query" would be a more precise name? 
      selector '.scope',
      testContainer: '.testContainer'
      // `resetScope` and `at`?
    } 
  }
}

@ro0gr ro0gr reopened this Jan 12, 2020
@ro0gr ro0gr changed the title Definition string value as a component selector Consider string as a scope Jan 12, 2020
ro0gr added a commit to ro0gr/ember-cli-page-object that referenced this issue Mar 12, 2020
in order to unlock any strings to be considered as a scope(san650#408) in v2.
ro0gr added a commit to ro0gr/ember-cli-page-object that referenced this issue Mar 19, 2020
in order to unlock any strings to be considered as a scope(san650#408) in v2.
ro0gr added a commit that referenced this issue Mar 26, 2020
in order to unlock any strings to be considered as a scope(#408) in v2.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant