v2 Release List

[justincy]

This tracks work to release version 4 of the FamilySearch Polymer components. The main goal of this release is to get rid of fs-behavior, migrate all existing elements to the Polymer v2 custom element v1 class syntax. This work paves the way for adding more elements and allowing elements to write to the API.

• [x] Kill fs-behavior #16
• [x] Create fs-api-aware
• [x] Update fs-client to the class syntax
• [x] Update fs-request to use new fs-client version, remove fs-behavior and use fs-api-aware
• [x] Allow fs-request to be used without attaching to the DOM https://github.com/fs-webcomponents/fs-request/issues/4
• [x] Update fs-signin
• [x] fs-request: option to wait until client is authenticated https://github.com/fs-webcomponents/fs-request/issues/5
• [x] Create fs-person-mixin to replace fs-person-behavior
• [x] Update fs-person-portrait
• [x] Update fs-person-summary
• [x] Update fs-person-card
• [x] Update fs-person-chip
• [x] Update fs-contributor
• [x] Update fs-person-facts
• [x] Update fs-person-families
• [x] Update fs-person-sources
• [x] Update fs-pedigree
• [x] Update sample app
• [x] Release fs-api-aware
• [x] Release fs-client
• [x] Release fs-request
• [x] Release fs-signin
• [x] Release fs-contributor
• [x] Release fs-person-mixin
• [x] Release fs-person-portrait
• [x] Release fs-person-summary
• [x] Release fs-person-card
• [x] Release fs-person-chip
• [x] Release fs-person-facts
• [x] Release fs-person-families
• [x] Release fs-person-sources
• [x] Release fs-pedigree
• [x] Release sample app
• [x] Update fs-elements-collection
  • [x] Add fs-api-aware
  • [x] Add fs-person-mixin
  • [x] Remove fs-person-behavior
  • [x] Remove fs-behavior

[justincy]

Polymer encourages the use of namespaces for mixins. An obvious choice for us would be FamilySearch but that's already used by the SDK. An alternative would be FS but that's already the prefix to the name we would use otherwise (e.g. FS.ApiAwareMixin vs FSApiAwareMixin) so we'll just remove the . and ditch the namespace idea.

[justincy]

fs-person-behavior was a useful extension of fs-behavior. It handled interaction with the client for elements that just needed access to a person. It allowed a person to be specified by ID, loaded the person and tracked loading state, then set the person property with the resulting data.

But now that fs-behavior has been killed and we have fs-request, we might be able to replace fs-person-behavior with fs-person-request. But even then I don't think we gain much. The amount of effort required to connect to a fs-person-request element would be almost the same for connecting to a fs-request element.

Two other features that fs-person-behavior provides are waiting for the client to be authenticated before making a request (again, we can add that behavior to fs-request) and allowing a person to be provided via an attribute and thus bypassing the load if a parent element already had the data, but with debouncing in the client and no usecases or plans to support these elements apart from the API then I don't see how that functionality is useful.

[justincy]

I'm wrong about not needing to allow the person object to be provided instead of requesting it from the API. A perfect example is the fs-person-families element. It makes one request to load the families and then displays the persons grouped in families by passing the person objects around to fs-person-chip elements. Debouncing doesn't help with that usecase. It'd be terribly inefficient to expect fs-perosn-chip to load all those persons we already have in memory.

[justincy]

Done