WordPress/wordpress-playground

Simple PHP class structure

adamziel opened this issue · 2 comments

Playground has many classes and interfaces referring to similar concept of PHP. There’s:

  • IsomorphicLocalPHP - sync interface for running PHP in the current process
  • IsomorphicRemotePHP - same as above but async for running PHP remotely, e.g. in a worker
  • BasePHP - base implementation of IsomorphicLocalPHP
  • WebPHP - ditto, but with browser specific methods
  • NodePHP - ditto, but with node specific methods
  • UniversalPHP – an interface with common parts from all of the above that returns either synchronously or asynchronously
  • WebPHPEndpoint - Async implementation of IsomorphicRemotePHP that calls WebPHP running in a worker. Used by client apps
  • PlaygroundClient – A postMessage facade that calls WebPHPEndpoint from another frame
  • ...and probably more.

I saw developers get very confused about this structure, especially with regard to why UniversalPHP and PlaygroundClient are often interchangeable. It is difficult to understand the structure and easy to update one but forget about another (and miss it in a review, see #490).

Let’s discuss and see if there can be a simpler structure that allows for:

  • Isomorphic PHP interface that supports web, node, and other runtimes
  • Same-thread PHP execution with synchronous method
  • Remote PHP execution, e.g. in a worker, with asynchronous methods

If it cannot be simplified, then at least let’s find a way to raise alarm bells in TypeScript if the PR makes a change in BasePHP but not in the other ones.

cc @eliot-akira @dmsnell @wojtekn

We're down to:

  • PHP – the same class used in the browser and in the CLI
  • UniversalPHP – an interface representing a local or remote PHP instance with limited set of methods
  • PlaygroundWorkerEndpoint - the worker API for interacting with Playground, exposes a boot() method to start the worker
  • PlaygroundClient – A JavaScript proxy object that forwards all the calls to PlaygroundWorkerEndpoint running in another frame
  • WebClientMixin – A remote.html-specific type that forwards PlaygroundClient calls to PlaygroundWorkerEndpoint and exposes DOM-specific methods such as goTo() that change the Playground iframe source

While it's 5 things and not 1 thing, I don't think there's a way to make this structure any simpler so I'll close this issue.