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

When config files are created during onboarding, keep them collapsed #23260

Closed
pstakoun opened this issue Aug 10, 2022 · 9 comments · Fixed by #23659
Closed

When config files are created during onboarding, keep them collapsed #23260

pstakoun opened this issue Aug 10, 2022 · 9 comments · Fixed by #23659
Assignees

Comments

@pstakoun
Copy link
Contributor

pstakoun commented Aug 10, 2022

During onboarding, when config files are created, keep them collapsed on the "Configuration Files" screens. If they have warnings (changes required, etc.), then start with them open.

Screen Shot 2022-08-10 at 4 55 42 PM

@brian-mann
Copy link
Member

I agree that all fields could be collapsed by default (except for conflicts as you suggested) with the exception of config.

Config should always be open because this is a one time operation and it’s important the user understand and see how their setup was translated into the lens of how that’s expressed through config. The goal here is to help orient, train, and teach the user what goes where to help them understand what’s available to them in order to further customize the config.

For instance the e2e and component functions are how you write plugins that can’t be autogenerated by us - it’s code the user has to write. There’s no UI pattern for doing this and we can’t lead you automatically to the things you’re trying to accomplish. Therefore it’s important to introduce the surface area that they will use in the future.

@brian-mann
Copy link
Member

Although I'm not convinced the config accordion should be collapsed by default, I'm okay with collapsing it by default and we'll keep an eye out for confusion from users.

@baus
Copy link

baus commented Aug 26, 2022

@lmiller1990
Copy link
Contributor

lmiller1990 commented Aug 29, 2022

Is there any case were we need changes/warnings except for cypress.config.js? This should only happen when setting up E2E or CT in a project that has already got 1 testing type, and when we update the cypress.config.js, something goes wrong.

I don't know of any cases where this would happen off the top of my head, so what is the deliverable here? I was going to suggest "open cypress.config.js by default", but it looks like this isn't something we are doing based on the above comment from @brian-mann?

It's hard to estimate the work required for this ticket when there's not clear use case where the cypress.config.js is not valid, and no obvious use case where any of the other files can be conflicted at all.

@rockindahizzy
Copy link
Contributor

We definitely will need to determine more concrete use cases/AC in order to have an idea of the scope of work for this issue.

@pstakoun
Copy link
Contributor Author

We should not be adding any warnings, etc outside of existing patterns. The use case is simply to reduce the amount of information the user is shown on this "config success" screen, so showing them the files created rather than all of their contents as well. @lmiller1990 @rockindahizzy maybe I'm not understanding the scope here - are these cases where the change is not as simple as: collapse file contents by default if and only if it is in the success state (green with checkmark)?

@rockindahizzy
Copy link
Contributor

@pstakoun, that clears it up for me 👍

@cypress-bot
Copy link
Contributor

cypress-bot bot commented Sep 5, 2022

The code for this is done in cypress-io/cypress#23659, but has yet to be released.
We'll update this issue and reference the changelog when it's released.

@cypress-bot
Copy link
Contributor

cypress-bot bot commented Sep 13, 2022

Released in 10.8.0.

This comment thread has been locked. If you are still experiencing this issue after upgrading to
Cypress v10.8.0, please open a new issue.

@cypress-bot cypress-bot bot locked as resolved and limited conversation to collaborators Sep 13, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants