This is a living document, and as of this writing is subject to (constant) change as we discuss along the roadmap of Dext
- Hooking system
- Distribution of packages
- Static typing on existing code base
At the moment, when plugin hooks into the query, they interact with the query from two entry-points: keyword
and copy
.
While this is good enough for simple use-cases, it's pretty inflexible, and leaving the plugin "locked" into a single action.
What could have been possible is treat the input as a possible query language, and let the plugins act accordingly.
module.exports = {
keyword: 'giphy',
action: 'copy'
}
module.exports = {
// keyword target for the plugin to hook into.
// we keep this option to avoid interoperability to which could be mixing concerns.
keyword: 'giphy',
action: (query, actions) => {
// `actions` is a simple object with less than a handful of functions aka "actions"
// provided by dext which are intermediate functions to core electron functionality
// with query === 'giphy cat copy'
request(url).then((img) => actions.copyToClipboard(url))
// with query === 'giphy cat open'
request(url).then((url) => actions.openDefaultBrowser(url))
}
}
Maybe it is time to consider lerna. What I personally dislike with what we have is that core plugins are spread across multiple repos, which could with time make hard and unrewarding to maintain.
I will quote a great sentence from a buddy of mine on this: Use typescript when writing from scratch, use flow when adding static typing to existing code base. We all know that a re-write is not a great idea at all. But I want to argue on starting to add static typing.
Not only is it helpful to avoid bugs, but it would force us authors to really think about API of functions, as well as store models and having a base to reason about.
Let's start somewhere. I want to suggest the following for the short term:
- let's start by cleaning up the code base; on all plugins including dext itself.
- add static typing and clean up our APIs
- Consolidate all repos of dext + core plugins into one repo
- Start designing a hooking system that makes plugin much richer than a configuration file.
Re-consider theme.
Core
although CSS-in-JS is fine by me, I really despise configurable themes and we get to see configurations leak
into and induces a mixin style of composing values to the theme:
Instead, we should just run the default theme as it is and for opt-in themes, we can think of the following:
External
For an external theme, why not accept react components?
Plugin export
Render phase of Dext
cc @vutran