Files
cypress/packages/data-context
Raymond Greeley efe577aa66 feat: Passing --browser flag alone will launch after test selection (#28538)
* Add localSettings field to OpenBrowser query

* Add wasBrowserSetInCLI as OpenBrowserList prop

* Emit launch on mount if --browser was passed

* Add entry to cli changelog

* Correct typo in changelog

* Add link to issue addressed

* Add pull request title

* Check if browser is already open before launch

* Moved features section to top of file

* Add reference to PR in changelog

* Correct unintended completion

* Add features to top of changelog

* Change prop name for convention

* Add isValidBrowser

checkes whether a cliBrowser is valid or not and
returns a boolean

* Add isValidBrowser to schema

* Use isValid browser

creates a function launchIfBrowserSetInCli that
will launch the browser if a valid browser flag
was passed to the cli

* Add to changelog.md

* Add global launch count to keep track project launch

* Make global count available to the launchPad

* Add description for globalLaunchCount

* Add globalCounnt to schema

* Remove unused import and remove unused prop

* Use launch function

* Import document and use query

* Add to changelog

* Add to existing features section

* Add to changelog

* Update changelog.md

* Add setter for launchCount and add tests

* Update changelog

* Remove extra bugfix title

* Update changelog

* Update changelog

* Update changelog

* Update changelog

* Update Changelog

* Update changelog

* Update Changelog

* Update changelog

* Fix changelog for line break error

* Update changelog

* Refactor to create single field for launching browser

* Update schema

* Refactor function to make use of single field

* Change launch count in beforeEach hook instead

* Clean up await in function

* Update changelog

* Add additional optional chaining for resiliency

* Use more precise browser launching query to fix silent bug

* Assert that launchProject hasn't been called when browser not found

* Update changelog

* Update cli/CHANGELOG.md

---------

Co-authored-by: Mark Noonan <mark@cypress.io>
Co-authored-by: Ryan Manuel <ryanm@cypress.io>
Co-authored-by: Matt Schile <mschile@cypress.io>
Co-authored-by: Jennifer Shehane <shehane.jennifer@gmail.com>
Co-authored-by: Jennifer Shehane <jennifer@cypress.io>
2024-08-27 10:22:40 -04:00
..

@packages/data-context

Centralized data access for the Cypress application

Directories & Concepts

There are several directories in src:

  • actions
  • codegen
  • data
  • gen
  • sources
  • util

The main ones you need to know about are data, sources and actions.

Here are some general guidelines associated with each, and an example showing how they are used together.

Data

This contains the interfaces that describe the top level data (called coreData) that is exposed and used by launchpad and app. Secondary data that isn't exposed to the outside world (temporary states, flags, etc) is usually in a Source. Sources are also used to derive data.

If you want to update Data, you use an Action (see below).

Sources

The sources directory contains what can be thought of as "read only" and "derived" data. Each one is namespaced based on the kind of data it's associated with, for example Project, Browser, Settings, etc. Sources can access the ctx (type DataContext, see DataContext.ts), using this.ctx.

If you want to update something in a Source, or in coreData, you want to do it using an Action.

Actions

Actions are where mutative and destructive operations live. To make this predictable and changes each to track, updating this.ctx.coreData should be done via an Action and use this.ctx.update, which receives the current coreData as the first argument.

Example

In this example, we will load some specs for a project and persist them. We will use a Source to derive any specs with the characters "foo" in the filename. This shows how Data, Sources and Actions are connected.

1. Define Data data/coreData

First we define the type in CoreDataShape and set the initial value in makeCoreData.

export interface CoreDataShape {
  specs: string[]
}

// ...

export function makeCoreData (modeOptions: Partial<AllModeOptions> = {}): CoreDataShape {
  return {
    // ...
    specs: [],
  }
}

This is where the actual value will be saved.

2. Define Action to Update Specs

We need some way to update the value. For this, we are defining a new SpecActions class inside of actions and updating the coreData with this.ctx.update.

import type { DataContext } from '..'
import globby from 'globby'

export class SpecActions {
  constructor (private ctx: DataContext) {}

  async findSpecs () {
    const specs = await globby('./**/*.spec.js')
    this.ctx.update(coreData => {
      coreData.specs = specs
    })
  }
}

Note: If you added a new Action file, you will also need to add it to DataActions.ts, although this isn't very common.

import type { DataContext } from '.'
import {
  // ...
  SpecActions 
} from './actions'
import { cached } from './util'

export class DataActions {
  constructor (private ctx: DataContext) {}
  
  // ...

  @cached
  get specs () {
    return new SpecActions(this.ctx)
  }
}

3. Derive the Data with a Source

In this example we only want to expose specs with foo in the name. We can derive this using a Source. This will be a new Source call SpecDataSource, but you can use an existing one if it makes sense.

import type { DataContext } from '..'

export class SpecDataSource {
  constructor (private ctx: DataContext) {}

  fooSpecs () {
    return this.ctx.coreData.specs.find(spec => spec.includes('foo'))
  }
}

If you added a new Source, you need to add it to DataContext.ts.

import { SpecDataSource } from './sources/SpecDataSource'

export class DataContext {

  // ...

  @cached
  get specs () {
    return new SpecDataSource(this)
  }
}

4. (Bonus) Expose via GraphQL

You might want to expose your new Data or Source via GraphQL. It's easy, since GraphQL also has access ctx as the third argument to the resolvers. For example, we can expose specs and fooSpecs in gql-Query.ts like this:

export const Query = objectType({
  definition (t) {

    // ...

    t.list.string('specs', {
      description: 'A list of specs',
      resolve: (source, args, ctx) => {
        return ctx.coreData.specs
      },
    })

    t.list.string('fooSpecs', {
      description: 'A list of specs containing foo',
      resolve: (source, args, ctx) => {
        return ctx.specs.fooSpecs()
      },
    })
  }
})