Decoupling the Rendering and the Logic

[nadeeshaan]

Hi guys,
We are currently (my self and @robertkowalski) are involved in a project (http://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015/nadeeshaan/5673385510043648) in fauxton to visualize the revision history of a couchDb Document and allow navigation and other document manipulation features. In order to do so we are willing to use your project as the base. Since we use React and Flux architecture in Fauxton we cannot use the current project as it is. In order to integrate this project with Fauxton, logic and the rendering should be decoupled. We Would like to get some feedback about this idea and the possibility of doing so.

[neojski]

Hi @nadeeshaan. I will do my best to help you!

Generally, most of the logic is pretty easy and all it does is call draw function that draws the image using paths, deleted, winner and minUniq (that I use to draw shorter names).

I think I'm in favor of making this visualizeRevTree use npm and browserify in order to make it more modular. Would it work for you? I'd say, export a function called getRevTree or similar. I can also tweak the API so that it suits your needs.

[robertkowalski]

cool sounds great!

maybe we can do this work in two steps:

1. make use of browserify, set everything up - then send a PR
2. refactor / expose the functions we need

what do you think of refactoring it so that using pouchdb gets optional (you provide a callback for each db action)

what do you think of providing a callback for the drawer which could also get injected by callback

@nadeeshaan @neojski what do you think regarding these three points (steps, callbacks for db, callback for drawer)?

[neojski]

Steps look good.

However, I'm not sure how would make pouchdb dependency optional. All this code does is get the data from couchdb using pouchdb API and then draw it. How is it set up in Fauxton so that you don't want pouchdb dependency?

What do you mean by the drawer?

[robertkowalski]

The drawer would be the renderer / rendering

In Fauxton we are using backbone models/collections for talking to couchdb

On Mon, May 4, 2015 at 4:51 PM, Tomasz Kołodziejski <
notifications@github.com> wrote:

Steps look good.

However, I'm not sure how would make pouchdb dependency optional. All this
code does is get the data from couchdb using pouchdb API and then draw it.
How is it set up in Fauxton so that you don't want pouchdb dependency?

What do you mean by the drawer?

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

[neojski]

I did some initial work of browserifying stuff. I'm open to your suggestions about point 2. Also, I'm open to contributions!

[robertkowalski]

wow awesome!

@nadeeshaan do you think we can use it?

[robertkowalski]

@neojski maybe you already solved point two :)

let's wait for feedback from @nadeeshaan

[neojski]

Just let me know what else you need. I can also publish it on npm.

[neojski]

@nadeeshaan and @robertkowalski, any news? By the way, do you have any links to source code where you want to use it? I'd be happy to see how it's used :-)

[nadeeshaan]

@neojski sorry for the late reply, since I have mistakenly missed the notification. At the moment we have converted the visualization in to react by using your logic. Some of the implementation has been bit modified in order to match the React implementation and flux architecture. Also you can find the current implementation here. Also I have to tell you your implementation logic is pretty amazing and which made our work easier. :)
apache/couchdb-fauxton#433

[neojski]

Oh, I see. It's a shame I couldn't make this code modular enough and you basically had to copy-paste it all. By the way, I'd be happy if I were mentioned somewhere as the original author of that code 😄 (or like contributor). How does it work in fauxton @robertkowalski, @nadeeshaan?

Before merging your project, please have another look as how we can improve on that. In particular, I suppose that visualization of the revision tree in fauxton will be maintained more than my project. I think that after this is fully copied into fauxton I can just start pointing to fauxton directly and leave a couple of screenshots here. What do you think guys?

[nadeeshaan]

@neojski we are definitely mentioning you as the owner of the core logic :) . We still did not do so since we are not in a merging state.
IMO linking fauxton directly here as you have mentioned will be really, really nice. @robertkowalski I think that is a good idea, would like to have your opinion also.
@neojski This is how the tree view looks at the moment.

[neojski]

Sounds great and looks really nice. Please ping me once you're ready so I can have a look and do the updates here.

[robertkowalski]

Hi @neojski

we are working on this project as part of the Google Summer of Code and of course we will add you to our NOTICE and LICENSE file, and also add a few comments in the source!

The main issue that we can't use it right now is that that a build including pouch is too heavy for us (we don't use pouch anywhere in our project, mainly because pouch did not exist when the project started).

I am quite busy these days, but it still bugs me a lot that we can't reuse at least parts of the code, so stay tuned. Thanks for your support so far, maybe @nadeeshaan has time to make PouchDB / data-fetching in general modular and decouples it and sends you a PR.

I think as we want to use your code we should work on the revtree project - I was quite surprised (in a positive way) that you already did a lot of the main work for us - thank you again!

@nadeeshaan is decoupling the data fetching something you could work on next week? I would suggest a callback / callbacks that you pass in that returns the data in the current format the jquery ajax and pouchdb calls return. Then this project uses a main entry file that still uses pouch and jquery ajax and the entry file for fauxton is passing in backbone models or data from backbone models.