Is it possible to get data from one package to another?

[manngo]

This involves two packages I’m writing.

Is it possible for one package to request and receie static data from another package? My thinking goes something like this?

//	Package 1:
	activate(state) {
		this.subscriptions = new CompositeDisposable();
		this.subscriptions.add(
			atom.commands.add('atom-workspace', {
				'package-one:data': () => this.sendData(),
			})
		);
	},
	sendData() {
		//	how do I send a response?
	}

//	Package 2:
	atom.commands.dispatch(atom.views.getView(atom.workspace.getActiveTextEditor()), 'package-one:data')
	.then(result => {
		console.log(result);
	});

I tried a simple return from the first package, but that was hoping for too much.

I read something about services (https://flight-manual.atom-editor.cc/behind-atom/sections/interacting-with-other-packages-via-services/), but I couldn’t see how the example suited my needs. I also get the impression that the package.json in Package 2 file needs to be aware of Package 1, which I’m trying to avoid.

Is there a solution?

[savetheclocktower]

Services are what you want.

With a service, Package 2 doesn't need to be aware of Package 1 specifically; it just needs to be aware of the service that Package 1 exposes. (Any alternative to services would still involve Package 1 establishing some sort of convention and Package 2 following it, so they'd be coupled no matter what. At least with a service, you're establishing an abstract contract that any other package could theoretically provide in the future in Package 1’s place.)

Package 1 would be the provider. Whatever method name you define should exist alongside your activate method and can return whatever you want. Most commonly it's an object with some methods on it. If Package 2 is configured to consume that service, it would get that object passed to a certain method at activation time; you'd store it as a property somewhere so that you could call it at will.

If you want to consult examples, look at how symbols-view and autocomplete-plus use services in the main codebase.

[savetheclocktower]

Not quite:

//	Package 1: package.json
{
  //	etc,
  "providedServices": {
    "some-service": {
      "description": "Exports Data",
      "versions": {
        "1.0.0": "provideSomeService"
      }
    }
  }
}

//	Package 1: main.js

const someService = {
  async doSomething() {
    return await performSomeAsyncAction();
  }
}

module.exports = {
  activate(state) {
    //	etc
  },
  provideSomeService() {
    // Is called once when both Package 1 and Package 2 have been activated
    return someService
  }
  //	etc
}

//	Package 2: package.json
{
  //	etc,
  "consumedServices": {
    "some-service": {
      "description": "Imports Data",
      "versions": {
        "1.0.0": "consumeSomeService"
      }
    }
  }
}

//	Package 2: main.js

let consumedService;

module.exports = {
  activate() {
    //	etc
  },
  consumeSomeService(service) {
    consumedService = service;
  },
  
  async doSomethingRequiringTheService () {
    if (!consumedService) return;
    return await consumedService.doSomething();
  },
  //	etc
}

So to review:

1. Both provider and consumer should use the same service name and version. (The description field is merely informative and doesn't have to match up, necessarily.)
2. When both packages are active, Pulsar sees that it can match up the provider to the consumer, calls the provider method, gets the return value, and passes it to the consumer.
3. You should guard against the introduction in step 2 never having been made (as would happen if the user had one of the packages disabled).
4. In this example, I defined an object called someService that has a bunch of methods on it… and that's the most typical pattern, but it could be anything. Just keep in mind the introduction happens once… so it's usually correct to pass one or more functions because it lets you defer the evaluation until such time as the function is called.

[savetheclocktower]

And, yeah, the documentation is rough here. I'll fix it.

[manngo]

Thanks for the fixed code. I’ve now got something working.

I’m still confused about one thing. What happens if another package wants to provide the same service? I wondered whether the consumer could choose which provider to fetch the data from?

[savetheclocktower]

No, the consumer would get both instances of the service. This is often the correct behavior for a service — e.g., autocomplete-plus wants to be able to consult a number of sources for autocompletion suggestions.

There's no logic built into the service system that allows it to pick and choose between providers; if it wants to be able to consult some metadata to know which one is “better,” then that metadata should be part of the service object itself.

(For instance: symbols-view also wants to be able to consult multiple symbol providers, but it usually has to pick a winner for each individual symbol-related task. So it builds that into the service contract. It calls a method on each provider saying “how well can you fulfill this given request?” and it responds with a score.)

[savetheclocktower]

By the way: here's the PR that aims to improve the service documentation. I probably threw too much detail in there, but at least it'll be more accurate soon. Maybe you'll find it useful!