Shared models/collections about aura HOT 5 CLOSED

This is an excellent question!

Sometimes you want to share a data-structure between your widgets, a Backbone collection being a good example.
This keeps it in sync and you dont have to worry about manually syncing two separate collections.

I have thought about a couple of ways this could be done.

1. Instantiating a collection and putting it on the sandbox
2. Creating a data access module that other modules could request data entities like models or collections from.

For the second option to work there would need to be created a more advanced way for modules to communicate.
At the least one should be able to not only listen/subscribe to other modules. But also make requests at them.

from aura.

There have been quite a few questions posted lately about how to effectively share data (e.g collections) between different widgets and I think the workflow you describe in your question is an excellent example of where this type of problem fits in well. I'd like for us to document an answer to this better.

One way a solution to your problem can be achieved is by calling .publish() from the sandbox with some extra data e.g

// task list
sandbox.publish('task', 'detail', id);

// task detail
sandbox.subscribe('task', 'detail', function (caller, id) {
  // Do things with id
});

where you can either pass around the collection data or a reference to where the collection exists elsewhere in your architecture. This is a little like the solution proposed by @gorillatron in 1.

2 is interesting as an idea and I'd like to see some code samples of what @gorillatron had in mind. One of the challenges with a data access module is that you want to make sure the module is providing more than just a namespace for where to place your collections.

When you place requests at them, what does that entail? Are you strictly asking for data that has already been returned from the server? Would you expect the data access module to be capable of handling more than this? I'd love to see a proof of concept of 2 implemented, but if you're tight on time 1. should be able to get you by.

from aura.

Ok, so Im actually working on my own litle library quite similar to aura, in tandem. Mostly for experimentation but I might make use of it in internal projects where I work.

And im playing around with another way for modules to interface without tight coupling.

// DATA module
var users = new UsersCollection()

users.fetch()

sandbox.registerInterface("data::users", users)


// USERLIST module
sandbox.requestInterface("data::users", function( err, users ) {
  if( err && err.code === 400 ) {
    return modal.error("could not find users")
  }

  var usersView = new UsersView({ collection: users })

  usersView.render()
})

This is very rough, but something im working on.

_Explanation_

When you register a interface the object you register is tied to the namespace you give it and when someone makes a request at the same namespace they receive the object.

If you want dynamic request handlers one could possibly let the interface itself be a function that is invoked every time someone requests it. Again, very rough.

sandbox.registerInterface("users::get", function( req, res ) {

  // pseudo for async fetch
  Users.all(function( err, users ) {
    res.send( users )
  })

})

sandbox.requestInterface("users::get", function( err, users ) { })

from aura.

@gorillatron +1!

I have historically had success with a shared "registry" module that implements the Service Locator pattern. To discover services/extensions, modules do something like:

var UsersModel = sandbox.registry.get("model:core.users");

Beyond just looking for one thing, the get (in retrospect, this could have been called "query") method returns an Array of results for when a module could be looking for a collection of things. It could have its uses if a method like "requestInterface" wouldn't just get locked down to a single returned item.

Maybe wildcards could also be supported for fuzzy interface collection (e.g. "give me all the fruits")...

Or even some semantic versioning for backwards/forwards-compatible querying of interfaces (e.g. "give me a Users Model that conforms to a 1.1.x schema")...

from aura.

Thanks for the discussion! Closing due to age of ticket and applicability to the refactor. Please feel free to reopen if you would like to address this via a pull request or specific solution with the current version in master.

from aura.