Future of dext

draft.md

Disclaimer

This is a living document, and as of this writing is subject to (constant) change as we discuss along the roadmap of Dext

---

Table of contents

• Hooking system
• Distribution of packages
• Static typing on existing code base

---

Hooking system

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.

Today

module.exports = {
  keyword: 'giphy',
  action: 'copy'
}

Ideal

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))
  }
}

---

Lerna

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.

---

Static typing on existing code base

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.

---

Roadmap

Let's start somewhere. I want to suggest the following for the short term:

1. let's start by cleaning up the code base; on all plugins including dext itself.
2. add static typing and clean up our APIs
3. Consolidate all repos of dext + core plugins into one repo
4. Start designing a hooking system that makes plugin much richer than a configuration file.

Core plugins

There has been back & forth discussions about whether dext should have some plugins out of the box or not. I say: yes we should have that.

Here the default behaviors I expect when I spin up a launcher:

• Web search
• (Installed) App search
• quickly save my clipboard to a text file
• Review clipboard history
• there is probably more, I welcome feedback on this

---

ref: DextApp/dext#126

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:

const themeSelected = selected
    ? compose(
      style(activeStyle),
      style(theme.resultActive || {})
    )
    : {};

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

const { div }  from 'styled-components'

export ResultItem = div`
    // configured style depending on state e.g `isHovered=true`, `isFocus=true` etc.
`

export ResultList = div`
    // configured style depending on state e.g `iOpen=true` etc.
`

Render phase of Dext

render () {
    const Theme = this.configuredTheme || DefautTheme

    return (
        <Theme.ResultList>
            <Theme.ResultItem />
        </Theme.ResultList>
    )
}

cc @vutran

O_O looks really interesting...

I believe the initial intentions was to model after an Alfred appearance JSON file but I think it may be best to start shifting away from Alfred compatibility?