Plugin and Store API Changes.

[louiss0]

I want to talk about Pinia's API. It's good but the problem with it is that it is in stores you define options with an options key at the end of setup stores. Then you use a random values at the end of options stores.
The problem with that is that plugins will read random values from the store. The developer has no control over which plugins are used and how. An option is just randomly used then a plugin or a series of plugins can be used on the same options. So instead of having random attributes as options or using random values at the end up setup stores. An options key can be put at the end and the name of each plugin can be used as the config name and the value for those names are used as the plugin options. In setup stores you can use just the plugin name as the config key and an object as the value.

Instead of this

defineStore('search', {
  actions: {
    searchContacts() {
      // ...
    },
  },

  // this will be read by a plugin later on
  debounce: {
    // debounce the action searchContacts by 300ms
    searchContacts: 300,
  },
})

import debounce from 'lodash/debounce'

pinia.use(({ options, store }) => {
  if (options.debounce) {
    // we are overriding the actions with new ones
    return Object.keys(options.debounce).reduce((debouncedActions, action) => {
      debouncedActions[action] = debounce(
        store[action],
        options.debounce[action]
      )
      return debouncedActions
    }, {})
  }
})

**You can do this **

// options are not used here because options are passed to the action plugin. 
function plugin({store, app, pinia }){

	return {
		// This is the id that will be used to pass options to the action
		configId: "debounceActions",
		// This is a function that will be run by the plugin
		action({debounce}){

	    if (debounce) {
	    // we are overriding the actions with new ones
	    return Object
	    .keys(debounce)
	    .reduce((debouncedActions, action) => {
	      debouncedActions[action] = debounce(
	        store[action],
	        debounce[action]
	      )
	      return debouncedActions
	    }, {})
		}

		
		}
	
	}
}

defineStore('search', {
  actions: {
    searchContacts() {
      // ...
    },
  },

  pluginOptions: {
	 // The key is the config id of the plugin that was used
	 // The object that is passed here will be passed to the action function   
	debounceActions:{
		// This is the options values
		debounce: {
	    // debounce the action searchContacts by 300ms
	    searchContacts: 300,
		},
	} 
 }
  
})

This will make pinia a better state management solution. The developer can control which plugins are being used on each store. Each plugin's action function will run in each time a store is used. A plugin could gain access to another plugin's action function or maybe rely on another one.

function pluginOne({store}){

	return {
		configId: "firstPlugin", 
		action(){
			store.$subscribe(()=> {
			
			})
		}
	}

}

function pluginTwo({pinia}){

	return {
		configId: "secondPlugin",
		
		action(){
			pinia.plugins.firstPlugin.action()
				
		}, 
		reliesOn: "firstPlugin"
		 
	}

}

I just want to consider making it so that the developer can choose which plugin will activate when a set of options are used.

[posva]

Sorry, I missed this. I personally like the freedom of having the flat API and allowing users to extend it in a way that feels native. It's also less verbose. Plugins are responsible of exposing an API that let users control where to activate them.

BTW plugins relying on other plugins still depend on plugin installation order.