joicomponents/book/chapter4_slotCallback/old/Pattern_BashfulCallback.md

Design patterns to build native web components

# Problem: TheSluttyDressEvent

> What if our animal instincts actually influenced our code? What if we as humans were not able
> to wipe our minds clean of our emotions when we program? No, surely, that cannot be. 
> To program is a uniquely rational activity. Of course our minds are 100% free from emotions when we
> program and that under no circumstance will emotional concepts influence our code.

## Dilemma: TheSluttyDress

"Is this dress too short?" she thinks. "Will they think I am slutty if wear it?"
This is a common dilemma for girls. Clothes communicate. The clothes you wear will become part of 
the interaction. Others will take a quick look at her encapsulation, and instantaneously start 
forming an opinion about who and what she is based on how she both protects and open up too what 
society's conventions define as private.

The solution to this problem should be simple, right? Why dress slutty at all? Why not just button up
a little extra, and problem solved?

Because then, as all girls know, you are not a slut, but a prude. Equally bad. You protect all your 
private parts, no problem there. But there are no openings. No way to start interaction. 
And therein lies the rub.
You don't want to be a slut, but you don't want to be a prude either. Normally. 
So, you have to find a balance. That little point on the unsymmetrical-twirling-baton between slut and prude
that is dresscodes for girls.

To understand this dilemma, we have to have a shared understanding of some basic concepts. 
Why do girls sometime so-called "dress like slut"? And, why is it that being a slut is considered bad, 
still, even in our post-gender modern society? And equally, why is it bad being a prude?

## Why be a little slutty, and not just a prude?

Despite human progress, boys will be boys and girls are still girls.
In fact, most boys and girls would still desperately like to live out their mammalian lives.
They seek to find a partner and get a baby. Not only that, they seek to find a nice partner. 
Someone that excites them. Both as civilized beings and as mammals.

So, an important part of girls' (and boys') communication via clothing has to do with them 
*communicating with others about their potential interaction with the opposite sex*. 
The more slutty the dress, the more a girl communicates that:
1. she wants to attract mammalian attention from boys because 
2. she is likely desiring more interaction with boys. Some of them. The girl is *more sexy*.

Equally, a prudish dress signals the opposite. A prudish dress says that the girl does not desire
"male mammalian attention" and interaction. She is *less sexy*.
Her encapsulation is so complete that the other elements at the party think it too much hassle
to interact with her. The prudely encapsulated ones stands alone, interacting with the wall.

## What's so bad about being a slut?

So then, why not just be a slut? Why not simply let it all hang out, always, and 
just say "no" when the boys come drooling?

The problem with a slutty dress is that it signals that too many elements might be interacting with your
privates. And while that might not be a problem for the mammalian girl directly, it is a direct problem
for the mammalian boy. If the mammalian girl gets input from many boys at the same time, then 
a boy interacting with her can get into a whole host of problems. If he is honorable, that is, 
interested in not only the interaction itself, but also of following up on the results from that interaction.

The first problem for the other element, is that if the slutty encapsulated element produces some result,
you cannot be sure that that result is meant for you. That the result is a product of her interaction with you
and not some other element. If the slut element's inner state can be unduly influenced by many other
elements at the same time, then the other elements cannot be sure that the output from that slut element
is theirs. Again, the other elements might define this as unproblematic, but if that is considered a 
problem by the other, male elements, then that indirectly becomes a problem for the slut element.
 
Encapsulation signals an element's monogamy. Too slutty encapsulation, and other elements don't trust it
to honor their input. They fear the slutty element can tell their secrets to others, that it can produce 
events that indirectly come from some other source. They fear both that their input can become distorted 
and lost, and they fear that the output from the slutty element might actually come from another source 
than itself. Without them knowing.

## Slutty or no? You never can tell.

The problem with slutty dresses is that their sluttyness is... relative.
Primarily, a dress is slutty or not depending on the point of view of the girl that wears it.
If a girl thinks that she is being slutty in a dress, that makes the dress more slutty.
But, even though some feminists will definitively disagree with me here, 
the girl cannot define a dress as slutty by herself. If the other elements think that the encapsulation
defines too loose protection of private parts and that they therefore cannot trust her with their
more longterm precious investment and input, then they define that encapsulation as too slutty.
Similarly, what the other girls at the party is wearing *also* affect a dress' sluttyness.
If all the girls' dress in bikinis at the pool-party, that knee-high tanktop that your mother 
thinks show FAR TOO MUCH leg and breast will seem kinda prudish. If yours is the only element that
require registering callbacks directly on that element, while all the other elements at the party just
blurts out events for the same thing, then your element's encapsulation which was totally appropriate
in another setting might seem just a little too prudish here.

## The SlutChangeEventDress

The `slotchange` event is a SluttyDress. When an element reacts to changes of their slotted elements,
then that is a private affair. The element might share information about such actions with others, 
but that should not be done automatically and for all, that should be done on a filtered, need-to-know basis.
The `slotchange` event is a too deep cleavage.

Why? There are several reasons (actually). 

1. As described in the previous chapter, `slotchange` is subject to SlotchangeEavesdropping. 
It is showing itself to elements that are actually *not* interested in seeing it.
This can confuse both the element emitting the slotchange event and other elements inadvertently seeing it.

2. events are always cast on the element. There is no way to cover the cleavage again.
If the element wanted the other elements *not to google her breasts*, she now can't.

3. There is another convention that other elements should use if they wanted information about slot
changes of an element: `MutationObserver({childlist:true})`. The others are perfectly capable of seeing
that there are breasts under the clothing; if they wanted to know, discretely viewing the curves on her
clothes is enough.

4. Why is attribute changes a callback, while slot changes an event? In my view, there is no good
rational behind this difference. On the contrary. `attributechangedCallback()` and `connectedCallback()`
establish a convention of callbacks for custom elements, and once this cultural expectation is established,
highly similar events such as slot changes should be handled the same way.

## bashful callbacks

To be bashful and shy is both an emotion and a demeanor. The bashful is at first encounter a bit reserved, 
inhibited, private and quiet. In new social environment they feel insecure and unsafe at first. 
They are afraid of being socially bashed and bruised. But, deep down the
shy desire social interaction. They like other people. And being socially sensitive themselves,
they are also more likely to be considerate of and respectful of others' social sensitivities. 
So, once new social situations become familiar and they feel safe, 
the shy and bashful will blossom, open up and be both a sensitive, interested playmate.

Lifecycle callbacks are bashful. Initially, the lifecycle callback is a private method.
Elements use their lifecycle callbacks to react to external stimuli *within* their encapsulation. 
This *in private first* approach gives the elements confidence that they control the situation,
which in turn gives them confidence when approaching other elements. 
Lifecycle callbacks are at first private, then extrovert.

Also, lifecycle callbacks promote a concept of mutual privacy.
When an element rely on lifecycle callbacks itself, it is easier for the developer to recognize similar
needs in other elements.

Finally, from the outside, elements with lifecycle callbacks are playful. 
They react to outside stimuli and changes in their environment without being directly told so.
And most do so in predictable ways. This makes them creative and fun to interact with.
 
## The BashfulSlotCallback

Sometimes when a person's inner emotion changes, he notifies his environment.
"You hit me on the nose! Now I am angry!! Grrr!!!". But more often, when a person gets emotional,
she keeps it to herself. And there are no absolute rules here. Some people show some emotions sometimes,
other people other emotions at other times. You never know. It is a minefield.

Now, think of an element as a person. 
When an element's internal state changes, the element sometimes notifies its environment.
And sometimes not. It depends on the element. And the internal change. Some internal changes 
should cause an external action, some not. And as with people and emotions, there are no fixed rules
that dictate what type of internal state changes that should always cause an external reaction.
It most often depends on the element, its previous internal state and the stimuli.
                                           
That is why a callback is a suitable trigger when an element's internal state changes.
The callback is bashful. Initially, it is private. When an internal change occurs, the callback first
assess the situation and, only if it chooses, extends its reaction externally.

And that is why the slutty `slotchange` event should be a BashfulSlotCallback.
`<slot>` elements are deeply private properties of a custom element.
When the content of such elements change, that is an internal state change.
It is up to the particular custom element in its current situation if this change should be made public.
While a `slotchange` event is broadcast publicly in the lightDOM of the shadowDOM in the custom element, 
a slotCallback() would be a private method by default, while still be free to choose to publish a 
custom external reaction from it if it deemed it appropriate.

The callback is a much better fit for the slot changes than the event.
It can be argued that `slotchange` events should never be intercepted by other elements than 
the `<slot>`s host element. If you want to alert the outside of the custom element, then 
you should do so indirectly via a custom event created by an internal `slotchange` event listener anyhow.
Second, slot change strongly resemble attribute changes as a change of an inner property.
Why handle slot and attribute changes via different interfaces.
A slotCallback is appropriately bashful. A slot event decision to always publish its finding is a little slutty.