Working through setting up a monorepo with Nx using their recommended concepts / mental model.
The starting library types specify that ui libs are to be presentational (dumb) only using only @inputs and @output. How would this work for something like a dropdown where the results need to be populated from an outside source without passing in the options every single time?
Even something as simple as an address state picker. It makes sense that it should be a reusable ui component (ui-address-input) but since it can't depend on data-access libraries to read the available state what's the correct approach?
Elevating it to a feature library seemed like an option but that would prevent it from being used as a block in assembling other ui libraries. But passing in the set of available states as an @input seems ridiculous since it will truly always be the same set of states once loaded and cached from the server so cluttering dozens and dozens of feature components with the service to get it from the cache and assign it to the address input seems ridiculous.
We're just not sure how to fit this into Nx concepts. We were considering another data-access type that indicates it's cached external retrieval (something like ui-data-access) and allowing ui libraries to depend on that. But is there a more correct approach for creating reusable ui components that load external data once under the standard Nx module boundaries limitations?