Data management

[plalx]

It might not be the best place to ask questions, however I haven't found a better communication channel.

I would like to know what would be an Aura idiomatic solution to the following question?

There's a similar problem in one of the Aura TodoMVC where a stats module needs to be provided with statistical data to do it's job. The way the problem is solved is that the todo-list module compiles the stats and emit a todo.stats event which is listened to by the stats module.

While this works, the stats module is completely dependent on the todo-list module to do it's job correctly. It is true that we could remove the todo-list module without "breaking" anything in terms of exceptions being thrown, however the stats module will also not be doing anything... and the problem just becomes worst as we add new modules that needs access/modify the todo's data.

I still haven't found a proper solution to similar problems (I exposed a few ideas in my question) and wanted to know what were the thoughts of the Aura community on this.

Thanks!

[plalx]

@addyosmani, @finalprototype, @sbellity, @genexp?

[svperfecta]

Hi @plalx - I'm sure you understand, everyone is busy, particularly on a weekend. In any case, I saw your question, and I wanted to respond.

As a framework, Aura offers a single way to communicate between decoupled components: a message bus (ie: pub/sub events). You correctly noted that there are a lot of cases where a single component (say, the stats component in your example) wouldn't really be used outside of some other component. In those cases it's up to you to decide whether its worth factoring it out of it's parent.

In my case, I follow a simple rule: Build monolithic components, and only extract out components for reuse when I have a reason to do so. I find this gives me a nice balance between code reuse and rapid iteration on the component I'm working on. Also, premature optimization is the root of all evil, so.... :)

I hope this helps!

[sbellity]

Hey @plalx, if you have a service that is supposed to "share" data between components i guess the best way would be to expose it as a service to all components via an extension.

You are right about the "stats" component in the todos example it's probably not a good example of decoupling between components.

[plalx]

@genexp Thanks for your response! However don't you feel that building monolithic components is contrary to the modular philosophy being exposed in the Nicholas Zakas presentation, where every module is a small lightweight unit that has a very specific task? Perhaps my example was too trivial to demonstrate the real complexity of the question I'm asking, but I do not think that it's reasonable to set my components boundaries based on the data they need to access. Is this what you propose or I misunderstood you?

@sbellity I agree that another layer (and perhaps more) seems necessary (e.g. a service), however this is where I find things gets more complicated and there is where I'm looking for more guidance.

• Should the modules directly interact with a service to fetch their data or should they be told their data (e.g. another layer fetches the data and inform the modules the data is ready throught a well-known communication channel)?
• How would you keep data in sync between every modules (e.g. how should data changes be propagated)? Should the services return models that can be observed by the modules or should application-level or service-level events be used?

Thinking about specific things I wanted to know made me realize that I had much more questions, that data sharing is quite a huge topic and it's scope probably goes beyond a specific framework...