API Working Group

Date 4/20/19

@MarshallOfSound to clarify on what experimental means in the docs
- PR was merged - electron/electron#22893
@codebytere to research Chromium's Intent to Implement / Intent to Experiment protocols
- Now called "intent to prototype"
- not a lot of hard requirements
- "intent to experiment" is the implementation phase. comes before an origin trial.
- after that "intent to ship".
- electron doesn't have origin trials
- chromium does about:flags -> origin trial -> off -> on for whole web
- devs can ship things w/ a --flag enabled
  - could read flags before JS starts? makes it more annoying for devs
- maybe the Experimental note in the docs is sufficient?
- maybe a case for "nightly-only" features?
  - when would this graduate into a full feature?
  - same as for regular commits
- maybe something like enableFeatures?
  - reusing chromium's content features api
  - could be enough friction to make devs stop & think
- Next step: spec doc. [@codebytere & @jkleinsc]
@zcbenz to make some revisions to the Views spec PR
- not the layout engine PR, this is the TopLevelWindow one
- this got merged 👍
@loc and @MarshallOfSound to review "get tab media stream" PR
- commented to ask for a change, no response
- #22701

docs: views API: child views and layout engine
- Should we build in YogaLayout or expose the underlying primitives?
  - Using YogaLayout would reduce API surface
  - Would need to update rollerbot to keep it up to date
  - Would using YogaLayout allow Electron to include React Native Views? - not without a lot of work
    - RN has its own JS engine as well as its own copy of YogaLayout
  - Let's spec out a "plan B" which exposes the lower-level building blocks?
  - [@zcbenz to update spec]
API review requested PRs
- feat: add desktopCapturer.getWebContentsStream() to get media stream id from web contents
  - Waiting for author response