Find a Permanent Home for the Attribute Service

[ThomThomson]

What is the Attribute Service?
The Attribute service is part of the 'Dashboard First' project. it is an additional layer of abstraction on top of saved objects that provides utilities that embeddables can use to more easily work with input that could be either 'by reference' or 'by value'. The AttributeService also contains a default implementation of the ReferenceOrValueEmbeddable interface which is used to determine if an embeddable supports both types of input, and used to move between both types.

Where has it been and why?
The attribute service was originally built as part of the embeddables plugin. The benefits of keeping it there was that every plugin that needed to use 'by reference' or 'by value' embeddables was already dependent on the embeddable plugin.

In #74302, the attribute service was moved into the dashboard plugin because the attribute service uses savedObjectClient, and there is a drive to avoid coupling saved objects and embeddables.

Options for homes
(in order of most hacky to least hacky)

1. The AttributeService could be kept in the dashboard plugin. This is the worst option, because it will introduce dependencies between the editor plugins e.g. visualize, lens, maps, and dashboard.
2. The AttributeService could be moved back into the embeddable plugin, complete with its coupling to savedObjects. This is not an excellent solution because of the aformentioned coupling, but would prevent all the editors from changing their dependencies
3. The AttributeService could be moved back into the embeddable plugin, with modifications to remove its coupling to savedObjects. This would leverage the AttributeService's customSaveMethod, and would make it instead required instead of optional. This would result in a slightly worse developer experience for using the attribute service, because each implementation would have to supply its own savedObject interaction logic, but would also make the attribute service substantially simpler.
4. The AttributeService could be moved as-is into a new plugin that the editors would have to depend on. This plugin could also contain the 'ReferenceOrValueEmbeddable' interface, and could be the future home for any 'by value' code. It could be called something like embeddable_by_value

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[ThomThomson]

After discussion with App Architecture, we have decided that option 3 is the best way forward.

In the future, when more 'dashboard first' specific features need a home, we may create a new plugin under the 'embeddables' domain, to store them all together. At that point we will be able to get to the fun part of deciding on what to name the plugin.

[ppisljar]

Thank you for contributing to this issue, however, we are closing this issue due to inactivity as part of a backlog grooming effort. If you believe this feature/bug should still be considered, please reopen with a comment.