Break up ObjectGraphHandler into several reusable components

ajvincent / es-membrane

An ECMAScript implementation of a Membrane, allowing users to dynamically hide, override, or extend objects in JavaScript with controlled effects on the original objects.

ISC License

109 stars 13 forks source link

Break up ObjectGraphHandler into several reusable components #179

Open ajvincent opened 6 years ago

ajvincent commented 6 years ago

In hindsight, having all the es-membrane proxies handle both membrane wrapping and distortions in the same proxy handler was probably a mistake. If I had a "membrane" level over a "distortions" level, the code might be simplified a lot.

ajvincent commented 5 years ago

This is going to be much harder than it sounds even to get started. I tried creating a redirection proxy handler, first as a barebones object (because I'd forgotten about ChainHandlers) and then as a ChainHandler. Neither approach worked immediately due to object graph handlers being instances of ObjectGraphHandler. (In the former case, I'd forgotten to define fieldName on the redirection proxy, which is an indirect assertion about the proxy handler.)

ajvincent commented 5 years ago

The design around this, I envision, starts with designing a Proxy handler which simply forwards trap calls to other handlers, in order to make the migration safer.

Trap handler migration checklist template:

[ ] getPrototypeOf
[ ] setPrototypeOf
[ ] isExtensible
[ ] preventExtensions
[ ] getOwnPropertyDescriptor
[ ] defineProperty
[ ] has
[ ] get
[ ] set
[ ] deleteProperty
[ ] ownKeys
[ ] apply
[ ] construct
[ ] Non-proxy unit tests
[ ] Proxy unit tests
[ ] Non-proxy integration tests
[ ] Proxy integration tests

ajvincent commented 5 years ago

Instead of trying to break up ObjectGraphHandler directly into several pieces, I need to build each component handler and unit-test that handler first . Then I need a set of integration tests for all of the handlers.

This means another build artifact for the handlers that we can import into tests.

ajvincent commented 5 years ago

Consider a two-dimensional map (proxy, handler) -> (metadata, nextHandler) design, with a default nextHandler on each one. That'll allow for inserting additional handlers in the middle with little trouble, and for storing metadata.