Welcome to ember-cli-page-object Discussions!

[san650]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[ro0gr]

That's great to see Discussions enabled! I think we've been missing a place to chat once ember's slack has gone :)

I'm a collaborator to ec-page-object for the last few years. Looking to move ec-page-object out of the Ember's only scope, and make it's core usable in different environments like Node, Ember or any other Web based project.

[san650]

Looking to move ec-page-object out of the Ember's only scope, and make it's core usable in different environments like Node, Ember or any other Web based project.

That would be very interesting to see. I've been creating different (similar) projects for other javascript frameworks before but never with the number of features that this library has. See https://github.com/san650/cypress-page-object and https://github.com/san650/ombu

It would be great to have a framework/library agnostic page object library that's also feature complete. I would love to hear your ideas on this subject.

[ro0gr]

Sorry for responding with such a delay. I had to wrap all my thoughts first 😅 So this is definitely consists of different efforts. And I'd like to make it from bottom to top, where the Cypress is a "top" and NodeJS/WebDriver is the "bottom".

Dependencies

First we need no ember-build specific dependecies in order to make everything importable by any regular JS projects. That means:

• ceibo can be imported by non-ember projects. I expect to fix it in the Multi-environments module format ceibo#23
• jquery can be imported by non-ember projects. This should be fixed in the next beta, specificaly Add embroider compatibility #556, and Re-align CI and test scenarios with Ember Defaults ro0gr/ember-cli-page-object#4. Also later I'd like to get rid of jquery at all, which is an old request here, but still doesn't seem to be a real blocker.
• no direct @ember imports. most of the work has been done in scope of the make it node.js compatible  #512_.
  At the moment, in the beta there is a single import like that. And the problem is that it is eager, cause for ember it makes sense to auto-setup the ember adapter by default. This would lead us to the next topic.

note: after all of these bullet points are addressed, we should be able to support nodejs, webdriver(and most of other envs like React, etc, with some caveats in their adapters)

Extract core

IMO, In order to address this bullet point:

no direct @ember imoprts

the most natural way to do it is to extract the most part of the package into a core lib, and avoid eager RFC268 adapter setup.

The only question to me here is whether we need a dedicated GH repo for that, or could we restucture the existing repo to become a monorepo(which is the best approach IMO) + rename it. As a result we should be able to:

import { create, setAdapter } from '@page-object/core';
// remark: this line should be never needed in reality, since for ember it should be set up automatically
import { RFC268Adapter } from '@page-object/ember';

@san650 WDYT? Are you fine converting this repo into a monorepo, with at least 2 packages for core and ember?

Async by default

In many frameworks(Cypress, React,...) there is no such a thing like Ember's settled(). When they invoke an action they just wait for an actionable element to appear. This is currently a missing/not-designed part of the ec-page-object(due to settled existance in Ember). I beleive for most cases, like React it could be solved by adding an "await-before-act" logic into an appropriate adapter for each action(which is not ideal, but should work). Though, for more integrity and support for more complex cases like Cypress, we'd need to keep the await-before-act logic in the core, and this needs a bit of design.

Actions

We just need some public API to declare actions. There is no any yet, but we are close enough, and I'd like to focus on it once v2 is released 😃