Closed bob2517 closed 3 years ago
Working on this now and it should be the next commit to the branch.
So in summary:
1) Existing privateEvents functionality is moving to new strictlyPrivateEvents. 2) privateEvents to inherit all parent scope events, in the same way privateVars can. 3) strictlyPrivateEvents will apply to all inner components if allowed.
That aligns the private scoping options to inherit in pretty much the same way as variables.
3) New combined option: private, which combines privateVars and privateEvents options. 4) New combined option: strictlyPrivate, which combines strictlyPrivateVars and strictlyPrivateEvents options.
Those last two just save on typing.
Note to self: There was a "private" option in 2.3.0 which was deprecated in 2.4.0. In 2.3.0, components were fully isolated and didn't inherit variables or events. "private" is going to be re-introduced with inheritance functionality as above but isn't going to work in the same way as 2.3.0, so that will need mentioning in the upgrade script with a replacement command for anyone upgrading from 2.3.0 to 2.5.0.
The replacement for anyone upgrading from 2.3.0 will be to change all component "private" options to "strictlyPrivate". That should give identical behaviour when this issue is complete.
Core upgrade sequence for this issue prior to publishing:
1) Convert all existing privateEvents variables in the core to have the word "strict" in them. 2) Introduce "strictlyPrivate" option. 3) Create new privateEvents option which allows CSS selection inside components - ie. inheriting outer events from outside the private component - this will be used in the todoMVC example for marking all tasks as complete and counting completed tasks, as the task component is a private component yet needs both variable and event inheritance. 4) Re-introduce "private" option which combines privateVars with the new privateEvents option. 5) Convert all components in the docs site, test suite and the code editor to use the new options. 6) Update the existing test code. 7) Finish off the todoMVC example. 8) Write a proper test suite. 9) Update the docs.
Found a bug. When running an inherited custom event from the document scope using the new privateEvents option after running an event from within the component, the target selectors and vars scoping are going a bit weird. It still thinks it's inside the component. It looks like it's a bubbling thing - the privateness of events in the component and the ability to select elements in a privateEvents component from outside work fine.
Added option for console-log as part of fixing this:
console-log: target;
That shows all the current states used when the console-log command is run - eg. the target object it is being applied to, the different scope settings, etc. Mainly for internal debugging purposes, but I guess it could be useful from a developer point of view. Will leave it in and get it in the docs.
Running that console-log command from inside an outer custom event that had been called from an inherited event shows a definite problem - the target selector scope did not bubble up in accordance with the event bubble. That explains why a couple of things aren't happening. Will fix that specific problem and see where it's at after that.
Fixed that, works as expected now. WIll do some more testing and hopefully commit this tomorrow.
Wasn't quite working right. Calling inherited events and custom events wasn't quite working as it should. Just done a commit which fixes the test cases I'm working on. Will continue on the todoMVC example and see if anything else comes up.
The ability to inherit events from outside of a private event scope is indicated for the area of components. For example, I need to reference elements by class all inner components in order to do something with all of them, but I can't get access to those outside component events because they are being called from inside a privateEvents component. But having a privateEvents scope is very handy inside a component, as it means I can reference elements without needing to add special IDs and classes.
But like the privateVars option can inherit variables from its parent component or document, the privateEvents option should really inherit events in the same way. Eg. it should be possible to trigger an outside event from inside a private component - those events should still be available. This would then inherit events all the way up to either the document or a "strictlyPrivateEvents" component for a fully self-contained component, while retaining the ability to call inner events with target selectors that only address those elements in the inner component and any further inner components.
The existing privateEvents option currently acts like a strictlyPrivateEvents option in that events only happen in that specific component. Target selectors are completely isolated to the component they are used within.
So, I'm going to make a change. PrivateEvents are now going to be able to inherit events from the parent scope, and strictlyPrivateEvents will act like the existing privateEvents behaviour, with the addition that they will also apply to any sub-components marked as privateEvents or not private.
This will add consistency to the way the private scopes are handled for both variables and events.
Of course, shadow DOM scopes will never inherit parent events, which follows native behaviour, so privateEvents and strictlyPrivateEvents on a shadow DOM component will both do the same thing.
Also, another possibility could be to add a "strictlyPrivate" option which sets up a component as having both strictlyPrivateVars and strictlyPrivateEvents. And a "private" option which sets up a component as having both privateVars and privateEvents. That should save some typing.
This will be part of 2.5.0. Existing components with "privateEvents" should have that option replaced everywhere found in config with "strictlyPrivateEvents" as part of the upgrade procedure and will be mentioned in upgrade notes. This will be a breaking change, but quick to remedy.
It's better that this gets done sooner rather than later, as having this seems really indicated - it wasn't particularly visible as needed functionality prior to this point. I'm pretty happy with the way components have turned out so far and I think this could be the last major change in this particular area.