Do we need to change or remove fs-behavior?

[justincy]

[Thinking out loud here.]

Now that fs-request has been created and manages interaction with fs-client, the majority of the functionality provided by fs-behavior isn't needed. All that's left is the clientName property.

That leads two a few ideas:

• isAuthenticated() - it's a pretty simple method. How often is it used? Can we get rid of it?
• getClient() - that is no longer needed once elements migrate to fs-request
• If we just have clientName left, should we still call it fs-behavior?
• fs-person-behavior depends on fs-behavior, but only for the getClient() method. However since behaviors have no DOM (and thus we can't use fs-request) we would either need to migrate getClient() into fs-person-behavior and remove the dependency or keep it in fs-behavior.
• Perhaps it's better to explore Polymer's 2.0 mixins and upgrade to that, which would be an excellent chance to upgrade all components to full 2.0 class syntax (that would be v4 of the fs components).

[justincy]

Docs for Polymer class mixins (not to be confused with CSS mixins): https://www.polymer-project.org/2.0/docs/devguide/custom-elements#mixins

[justincy]

More thoughts.

The naive implementation of fs-request would have fs-client in it's shadow DOM. I initially didn't want that because it seemed like a waste of resources to create a shadow root for an element that had no impact on display. However I was forced to follow that route initially because fs-client wouldn't work unless it was attached to the DOM. I tried to modify the behavior of fs-client to use property observers instead of ready() but was surprised to have the same issue. I settled with just manually calling configuration methods on fs-client from fs-request and kept fs-client in memory.

But that is all against the grain of Polymer. Why bother using an element in memory? Why not just use an object? I noticed that google-analytics-loader is a functional display-less element that includes other display-less elements in it's shadow DOM. It's declarative, in line with custom elements ethos, and provides nice encapsulation by guarding the components and internal behavior. So I think I'm sold on using the shadow DOM.

An implication of this is that now I have a usecase for fs-behavior that includes using both the clientName property and the getClient() method which means we may not want to split those as described above.

[justincy]

fs-behavior provides three pieces:

1. clientName property which allows all fs elements to optionally specify which SDK client will be used.
2. getClient() method which enables elements to access the SDK client.
3. isAuthenticated() method which is just a helper for determining whether the SDK client is authenticated.

clientName needs to be exposed on all fs elements that need API access. Perhaps we split that into a behavior (class mixin) called fs-api-enabled or fs-api-aware like google-signin-aware.

getClient() will be used by fs-request and fs-person-behavior but it's so simple that we could just copy it into both.

isAuthenticated() is used by:

• fs-signin, though it could just as easily bind to the authenticated property of the client; in fact that would be more correct instead of duplicating that property's purpose
• fs-person-sources, fs-person-families, fs-person-behavior, and fs-pedigree to make sure the data isn't requested until the user is logged in; we could easily add that functionality to fs-request

[justincy]

I think I've convinced myself that we can kill fs-behavior.