Transferring current Dashboard UI to React

[blackforestboi]

The current Dashboard UI needs to be translated to React.

Stefano already worked on the basic set up in the branch refactor-react and transferred the first page "Feedback" there. Its in the folder: https://github.com/WorldBrain/Research-Engine/tree/refactor-react/src/client/src/routes/Home

This should actually be completed before working on the web-results view.

@ShamariFeaster takes on the refactoring of the logic code and simultaenously we transfer the dashboard. When both are finished, we can stitch them together.

---

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

[blackforestboi]

Work that has already been done for this you find here: https://github.com/WorldBrain/Research-Engine/tree/refactor-react

not finished yet.

[ShamariFeaster]

So here are my thought on the react transformation. React's is designed to be create complicated, performant UIs. Rewriting essentially static UI with basic inputs (like the preference page) in react seems unnecessary to me. That said, I'm aware the other goal of the react transformation is it makes the code base isomorphic (ie, cross platform). That being said, we could essentially port the app as is over to a "mobile app" a la phonegap. this would mean serving up the entire app in webviews. But that's too far on the other end of the scale. The performance and UX for those kind of apps suck.

I suggest we only rewrite parts of the UI that will benefit from React and React Native's performance (like the results page...a potential huge memory hogging listview in mobile terms). All the other pages that are essential static HTML (preferences) can be kept as they are (albeit made responsive to accommodate various device/screen sizes ) and served up via webview's to the user. I've posted link to a couple discussion that show this "hybrid" approach (true React + plan HTML) will in fact work across platforms.

loading bundled HTML using react native

getting information from webview to react native components

react native implementation of pouchDB

[obsidianart]

the 2 static pages are already ported, I don't see any advantage in the standard html.
For example, the sidebar is a shared component in those pages, how do you import the sidebar in the static page?

I've done hybrid pages in the past loading React for specific elements but I find it worse at the end, the routing system is partial, the entry point more error prone, etc.

About the choice of React instead of static pages I have the following:

• guaranteed clean html (JSX doesn't allow html mistakes)
• reusable components (sidebar, header, etc)
• clear event handler (you can see every page now throws error)
• routing
• clear importing system (not React directly but comes with it) for scripts

About the native app, I wouldn't choose react for that, webview are way easier and even with the react approach I would think of using webview first (react native is painful). I'm not sure of what the app is supposed to do but it seems far in the future.

[ShamariFeaster]

If the porting is already done and if it's been decided that React will be used for the results page either way this means the new dev deps (Bable) are in the project already then we might as well just go with it.

Earlier in the process, I would've argued that React is overkill when one considers the app's lack of complex components. If decomposition (ei reuse) and routing were goals, there are much simpler tools for those jobs (Vue.js, Templar, etc). As for the eS6-style importing, I would argue that is a solved problem since browserfy already allows support of "require" which is more than sufficient for clear dependency resolution. Regarding HTML linting, in my experience incorrect HTML has never been a big enough issue to warrant a compile-time solution like Babel, especially if HTML linting is the only remaining "issue" not handled by tools in the existing stack.

It does, however, appear that the ship has sailed. Going forward, I would suggest that adding new tools to the stack ought to be carefully considered.

• Do we currently have a tool in the stack that satisfies some/all our new feature needs?
• If so, what new feature needs remain?
• What is the smallest, simplest new tool we can find to handle the remaining needs/upgrades?

If our goal is to encourage community contribution and involvement, our goal should be to keep the barrier to entry as low as possible: in terms of

• time to source comprehension (how quickly can a newbie browse source and understand)
• time to minimum tool proficiency (assuming potential contributor is new to tools in stack)
• minimum change iteration time (how fast one can see their change live)
• build rot sensitivity (will the build work 2 months later after a stack upgrade? Think the horror of building an old project in android studio)

[blackforestboi]

@aquibm also has a few words to say to it, he is in new zealand though (night time)

His first comment though was that he supports @obsidianart's point. He will lay out his reasing (in his) tomorrow.

[blackforestboi]

@ShamariFeaster thanks for your thoughtful input (havent seen the change before posting the response)

Agreed to your requirements for new frameworks. (At least from a non-developer point of view :) ) We really should make it an inclusive community and make it easy for people to contribute.
For the future, we should put more time into discussing the frameworks we use and measure them with those requirements. (any other requirements that people have in mind)