Reduce complexity of the plugin API
See original GitHub issueI think API should be vanilla NodeJS friendly. Babel and friends don’t help developers at this point and using legacy decorators and other early features shouldn’t be recommended. Please keep the API simple.
I could write the plugins like this now without Babel configurations but decorators looks bad to be honest.
const { Plugin, Command } = require('neovim')
class TestPlugin {
splitV() {
this.nvim.command('vsplit')
}
}
Command('Vsplit')(TestPlugin.prototype.splitV)
module.exports = Plugin({ dev: true })(TestPlugin)
Issue Analytics
- State:
- Created 6 years ago
- Reactions:1
- Comments:26 (17 by maintainers)
Top Results From Across the Web
Minimizing Microservices Complexity with Reusable APIs
Reusable APIs address the problem of complexity by allowing multiple applications to rely on a few independent microservices that expose the ...
Read more >java - Reduce its Cognitive Complexity from 59 to the 15 allowed
Cyclomatic complexity is mostly about levels of nesting decisions, so try to reduce branches. But this code has more serious problems than that....
Read more >CognitiveComplexity - Rider Plugin - JetBrains Marketplace
Implements live calculation of the Cognitive Complexity metric, which was proposed by G. Ann Campbell in Cognitive Complexity - A new way of...
Read more >complexity - ESLint - Pluggable JavaScript Linter
This rule is aimed at reducing code complexity by capping the amount of cyclomatic complexity allowed in a program. As such, it will...
Read more >Tool Time: Preventing leaky APIs with jQAssistant
Having a clearly defined API helps to reduce complexity for the user (they only need to learn and understand the API classes but...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I don’t know if any work has been done on this, but I’ll offer another suggestion! My preference would be strongly against any global object being either injected or required.
Defining a plugin by exporting a single function which takes nvim as an argument would be ideal for testing via dependency injection etc. The functions to register commands could exist on the nvim object.
This would allow whatever programming style you prefer, functional or OO, eg:
I would also love an official way to listen for arbitrary events sent by rpcnotify. I’m currently hacking around this with the following:
It would be nice to have
nvim.registerRPCHandler('EventName', fn)
instead.I’m happy to put in a PR for a different plugin API if it won’t be duplicating work.
I agree, I’ll explore a simpler API for creating plugins