Just to be clear, Angular is now also built on components, transpiled and a rich toolset, including debugger, unit testing, end-to-end tests, CLI with scaffolding for adding new components/services etc.
Building using components will also help prepare the new UI for a plugin architecture where Solr contribs/plug-ins add their own UI menu items and screens dynamically (dynamic loading vs build-time compiling). The old UI grows with more screens and features week by week so the burden of switching does not become smaller if we wait. Upayavira, moving from jQuery to AngularJS took the approach of building a clean parallel code base, with the downside of years of maintaining two UIs. Do you see any better approach this time around? Jan Sendt fra min iPhone > 15. apr. 2018 kl. 14:20 skrev Upayavira <u...@odoko.co.uk>: > > > >> On Sat, 14 Apr 2018, at 4:40 PM, Alexandre Rafalovitch wrote: >> Hello, >> >> The relevant JIRA is SOLR-12196, but we felt this deserved a greater >> discussion. >> >> Basically, our Admin UI is currently using AngularJS (1.x) as its >> Javascript framework. That particular library has reached its >> evolutionary end long time ago and is about to stop being supported >> all together. The later versions of Angular carry the same name, but >> are _very_ _very_ different. So, despite the heroic efforts that got >> us here, we are facing this choice again. Also, as we were just trying >> to migrate the UI and not rethink it, the underlying design/file >> layout/plugin architecture is also quite problematic. >> >> The question is what is the right thing to do next. There are >> basically four options: >> 1) Migrate to the latest Angular in an incremental fashion (as per >> JIRA's original proposal) >> 2) Jump to a different library (such as React or Vue) which got a much >> stronger momentum and ecosystem these days, but sort of keep current >> architecture (UI feel/approach) >> 3) Go blue-sky with new library and actually put some deep thought >> into modern UI leveraging Solr's current features (Management API, >> JSON, etc). Also, by picking React (for example) we get access to the >> ecosystem of modern tools, extensions and even potentially mobile >> apps. >> 4) Drop our own UI and adopt somebody else's (I don't have any good >> suggestions here though)? >> >> Normally, option 1 would be the sane one. The challenge is two fold though: >> a) Even option 1 is a lot of work due the Angular team's radical >> change of direction. Enough that it will lock us out from any other >> option for at least another 3-4 years. >> b) We are all server-side developers. So, even the simple Javascript >> things are hard for us, never mind the CSS part. So, this makes the >> cost of starting with any new approach dis-proportionally hard. Once >> going, it is a bit easier, because the advanced concepts are similar >> to other languages. >> >> All of these, combined with all the open JIRAs on Admin issues - to me >> - make option 3 less crazy than usual. >> >> What do others think? Is there discontent with the current state of >> Admin UI (apart from the implementation choice)? Are there secret web >> designers here, willing to get us over a bump of migration? Is there a >> company out there, willing to sponsor relevant skills to let us >> leapfrog the incremental upgrade (similar to how we got the Reference >> Guide). > > As you know, I'm responsible for the current UI. The aims in building this > version of the UI were to keep the visuals entirely the same, whilst reducing > the size and complexity of the underlying JavaScript (we reduced it by about > 50% in terms of LoC). The bulk of the work in its implementation was in terms > of understanding the intent of the existing code. Reproducing it in new code > was a smaller task by comparison. I hope this will pay off in any future > rewrite. > > At the time, the JavaScript landscape was changing fast. It was clear that > anything we produced would only be valid for a number of years. It seems we > have now reached that limit. > > I have recently taught myself basic ReactJS. It is clearly a powerful beast. > The two major distinguishing factors from the current UI are its > componentised nature (which means you don't build pages, you build re-usable > components) and that it uses a transpiled language. > > To rebuild the current UI in React, we would need to decompose the HTML pages > into components, and migrate behaviour into those components. > > Using a transpiled language (and all the tools that support that, e.g. > webpack) would give us a more compact, and modern, UI. > > However, the HTML is growing old. It isn't properly responsive, and it > doesn't use idioms that people have come to expect from a UI (e.g. no > hamburgers). > > In theory, I would support a rewrite of the visuals - it would make Solr seem > more modern. However, I do not underestimate the amount of work involved. > > Upayavira > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org >
