Jan, The plus of the Angular upgrade path that I saw you mention elsewhere was that you could have both old and new Angulars running in the same app, and migrate slowly. That would work for a change of backend, using the same styling. It really depends on what your goal is: a refreshed UI or getting rid of AngularJS. My aim was to keep the UI the same as this gave a very clear way to validate success. If you change the UI at the same time, identifying success becomes harder. Also, replacing the backend without changing the UI is quite possible with limited graphic design skills. Modernising the UI would require a different set of skills, and would probably involve us bringing in a UI designer from somewhere to give us mocked-up components to start from. So really, the question as to how best to do it will likely depend on who is doing the work. Upayavira
On Sun, 15 Apr 2018, at 6:13 PM, Jan Høydahl wrote: > 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 <[email protected]>: >> >> >> 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: [email protected] >> For additional commands, e-mail: [email protected] >>
