Re: Re-vamping the history tab

Sounds good. We are going to start by working on the tree.

On Fri, Mar 24, 2017 at 2:46 AM, Ashesh Vashi <ashesh(dot)vashi(at)enterprisedb(dot)com
> wrote:

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