Web Interface for search results and filter options

[blackforestboi]

Currently users can only retrieve 5 results at a time via the drop down of the address bar and have limited filter options. Right now I can only filter for the time and this also only by typing i.e. after:"yesterday".

We need a relatively simple web interface that can be run locally and lets users filter for various metrics:

• Keywords (via search bar)
• Timeframe
• Author
• Source

Mockup:

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[blackforestboi]

note:

Before starting, we should make sure, that we prepare this web view is later also able to display other sources (like evernote results etc)

We don't have to do it now, as we want to develop whats ultimately necessary for now, but keep in mind, that we will add more sources later, that are not web results.

[blackforestboi]

@obsidianart @hoshomoh
What is your stance on implementing this part (and refactor the other assets) in React.

This way we can easily port it to mobile and other platforms later.

[obsidianart]

I would personally use react, but I don't have a strong reason for it instead of something else (at least for now).

[blackforestboi]

It's also important to consider the future requirements of the tool:

1. We will have mobile applications for iOS and Android
2. We will have a native OS application (OSX, Win, Linux), possibly as an Electron App
3. We will have parts of the software run server side.

Any other requirements that come to mind?

So a framework will be useful that allows us to not redo work for each platform we develop our tool.
React seems suitable. Anybody sees downsides to it or limitations?

[blackforestboi]

@amitkumarj441 @Treora @hoshomoh @obsidianart

[blackforestboi]

Ok, So @obsidianart and me have just been spending our evening holding hands and setting up the base react framework.... :)

@aquibm Now we can start working on this part.

Important: check the #82 and give some feedback on the chosen architecture before starting. Thanks!

Basically what we need is a simple results view that covers the current functionalities of the address bar search.
It does not need to be connected to the actual functionalities yet.

It just needs to be able to input:

• the search query
• time picker with two fields

and output:

• Title of page
• URL of page
• Text of page with highlights (highlights are coming from pouchDB-Quick Search)

Updated Mockup:

[obsidianart]

I would try to keep the design the same (sidebar and header) and add this functionality within the routed view. For getting data from pouchdb you can use a middleware (which is the most elegant solution) but I would keep it simple and call the functionality from what we have (within the action/reducer). #82 has a nice approach to reducer keeping them at component level, I've never used it but I can appreciate the idea behind it.

[blackforestboi]

I would try to keep the design the same (sidebar and header)

Good idea!

Question here: can we call the results page then via a short cut/a fixed URL? This would greatly enhance the work-flow for people.
Also necessary because one option to enter the view is to chose the first result from the drop down, which then opens the web view.

As it seemed with memoryHistory, we dont have specific URLs for each the views anymore?

[obsidianart]

I think we can go back to hashHistory, the problem memoryHistory was supposed to solve didn't change. memoryHistory is probably good for the popup.html (which we don't need).

[blackforestboi]

Oh I thought memoryHistory did solve the problem?

But whatever is clever then. the search page just needs to be able to be callable with a URL then. Can we also pass the query via this url?

[obsidianart]

nope, we solved the problem in another way. you can pass the query in the forma #/search/query

[ShamariFeaster]

I'm guessing react is the current choice because it's isomorphic? My thoughts would be that if what the web interface has to do is relatively simple (display results in as table, paginate, etc) then maybe react is overkill? I'd be curious to see, concretely, just how isomorphic a react code base really is. Maybe something like Vue.js might be a better fit?