Re: [pgadmin-hackers] Re-vamping the history tab - Mailing list pgadmin-hackers

On Thu, Mar 23, 2017 at 1:51 PM, Atira Odhner <aodhner@pivotal.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.

> 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.
>
> Using react will make it easier to avoid situations like the one that has
> developed with the server tree bug.
>
> 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.

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.

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.

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