Re: Re-vamping the history tab

On Thu, Mar 23, 2017 at 8:23 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:

> On Thu, Mar 23, 2017 at 1:51 PM, Atira Odhner <aodhner(at)pivotal(dot)io> wrote:
> >
> > We will use jquery to make ajax calls that fetch the history data, but
> > actually rendering that data and managing the data once it has been
> fetched
> > will be handled with React.
> >
> > Backbone is not as powerful as React, and does not provide the ease of
> > ensuring a consistent state:
> > for example, which tree node is expanded and which context menu applies
> to
> > each node.
> >
> > Granted, the history tab has less state to manage than the tree. It still
> > has some:
> > which row is highlighted in the left panel and which data is displayed in
> > the right.
> >
> > That's part of why I think the history tab is a good place to start with
> > React. it is a simple demonstration of the way React will drop in.
>
> I think it's a poor example; firstly because those of us that will
> have to review the code will have zero experience at that time, and
> secondly because it doesn't really give us a good basis for
> comparison.
>
> A rewrite of a treeview node or two and something like the Grant
> Wizard would likely be far more convincing, as they would allow us to
> make an apples to apples comparison, and really understand the
> practical differences between the two technologies.
>
> I'd also want a committed plan to migrate - I do not want to end up in
> a situation where we have a mish-mash of backbone and react for any
> real period of time.
>
First impression of react from blogs, sites are looking promising.
And, I am not against changing it.

But - I agree with Dave.
Using the new technology with new feature will not give us the metrics for
comparison.

>
> > Backbone tends to leak memory over time unless you are very careful about
> > unbinding events when re-rendering. So users switching between various
> items
> > in history tab may have a degraded experience over time if we use
> backbone.
>
Agree - we need to be extra careful using the Backbone, when attaching the
events.
Specially - when we attach them from the 'render' function.
(Also - there are many corner cases, when we need(ed) to be careful.)

We tried that the same with the current implementation.
I won't claim - it's completely leak proof.
But - we always improved over the period of time.

> >
> > Using react will make it easier to avoid situations like the one that has
> > developed with the server tree bug.
>
Hmm.. I do not agree here.
Yes - there is a bug, and we need to fix it.
How does it make it easier to

>
> > Pgadmin4 is a heavily client-side application, and its Javascript code
> needs
> > to be treated as a first class citizen. The same principles of needing
> to be
> > highly componentized, easily understood by future developers, and readily
> > changeable should be applied to the front end code.
>
True, we could have done better.

>
> For sure - we also need to be mindful of bloat and having
> half-implemented changes (which is really is my biggest issue here)
> that we end up having to maintain for years to come. Worst case
> scenario for me would be that your team starts a migration project,
> whilst my team builds new features on that work, then for whatever
> reason, the Pivotal team stops the work halfway through, leaving us
> with a mess of code that we cannot easily fix without finding a bunch
> of resources.
>
+1

>
> I will stress that I have no reason to expect Pivotal to do that, but
> I have been burnt in that way by other (now defunct) Postgres
> companies and recovery took years.
>
Agree with Dave here.
Backbone is tightly bound with the application at the moment, and replacing
it will need lot of thoughts, consideration, planning, and commitment.

> Here are some resources on react for the interested:
> >
> > React vs Backbone:
> > http://www.code-experience.com/react-js-vs-traditional-
> mvc-backbone-ember-angular/
> >
> > React vs Angular:
> > https://medium.com/@paramsingh_66174/angularjs-vs-reactjs-e651a194dfcb#.
> oopgbfq3z
> >
> > Another quick take on why react:
> > https://www.syncano.io/blog/reactjs-reasons-why-part-1/
>
> It certains sounds like it would be a good move from a purely
> technical perspective.

+1

-- Thanks, Ashesh

I absolutely need to hear opinions from the EDB
> team though (CC'd).

> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>