You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Alexandre Rafalovitch <ar...@gmail.com> on 2018/04/14 15:40:33 UTC
Next steps for Solr Admin UI - request for in-depth discussion
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).
Regards,
Alex.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Next steps for Solr Admin UI - request for in-depth discussion
Posted by Upayavira <uv...@odoko.co.uk>.
On Mon, 16 Apr 2018, at 6:53 PM, Alexandre Rafalovitch wrote:
> > It really depends on what your goal is: a refreshed UI or getting rid of AngularJS
>
> I think that's an interesting question. Do we _know_ how a refreshed
> UI could be better than what we have now?
> *) Better mobile UI was one suggestion
> *) Reviewing it myself, I feel that there is lack of clarity whether
> some information/operation is Global, Collection-level, Core-level, or
> node-level. E.g. "Dashboard, java properties and thread dumps" are
> actually node level, next to Cloud, Collections and Suggestions that
> are global level. Next to logging, which I am guessing is a node
> level.
> *) Query screen had a number of requests against it, especially in
> regards to newer features
> *) Pluggable UI (e.g. for DIH) was a request and other plugins
> (/browse?) would probably enjoy a hook too (though it did not work out
> with admin-extra.html so much)
>
> Because that's the first question a "UI designer from somewhere" will
> ask, even if we could have an access to one.
It is worth noting the heritage of the current UI. It was a reworking of the old, ugly JSP admin UI in 3.x. It more or less took the same pages and made them (much) more beautiful.
Then the angular one took that and gave it a newer backend. And then collections awareness was added.
Each of these were additive, leading to a little bit of an architectural mess.
So I think you are right - the first step is one of information architecture - how do we present all the details. That could then be presented to a UI designer if we found one. And one might be easier to find if we had the architecture.
Not only that, it might be possible to start building using something like Bootstrap or MaterialUI, and style it later - i.e. just following conventions rather than doing 'design'.
Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Next steps for Solr Admin UI - request for in-depth discussion
Posted by Alexandre Rafalovitch <ar...@gmail.com>.
> It really depends on what your goal is: a refreshed UI or getting rid of AngularJS
I think that's an interesting question. Do we _know_ how a refreshed
UI could be better than what we have now?
*) Better mobile UI was one suggestion
*) Reviewing it myself, I feel that there is lack of clarity whether
some information/operation is Global, Collection-level, Core-level, or
node-level. E.g. "Dashboard, java properties and thread dumps" are
actually node level, next to Cloud, Collections and Suggestions that
are global level. Next to logging, which I am guessing is a node
level.
*) Query screen had a number of requests against it, especially in
regards to newer features
*) Pluggable UI (e.g. for DIH) was a request and other plugins
(/browse?) would probably enjoy a hook too (though it did not work out
with admin-extra.html so much)
Because that's the first question a "UI designer from somewhere" will
ask, even if we could have an access to one.
Regards,
Alex
On 15 April 2018 at 19:04, Upayavira <uv...@odoko.co.uk> wrote:
> 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 <uv...@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Next steps for Solr Admin UI - request for in-depth discussion
Posted by Upayavira <uv...@odoko.co.uk>.
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 <uv...@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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
Re: Next steps for Solr Admin UI - request for in-depth discussion
Posted by Shawn Heisey <ap...@elyograg.org>.
On 4/15/2018 11:13 AM, Jan Høydahl wrote:
> 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?
I'm onboard with writing a whole new UI in a more modern framework. I
would love to help, but I feel that I'm not well qualified, because my
understanding of Javascript and CSS isn't as complete as I think it
needs to be. I'm not completely useless in those fields, but it takes
me longer to figure out how to do things.
I think we should do a similar switchover -- build a new UI, make it
optional at first. We could wait for 8.0 to make it primary, or if we
feel it's ready, make it primary in a later 7.x release. Then we can
remove the old UI in the next major version after the default changes.
As soon as the new UI is made primary, the old UI should have a note on
every page saying that it is no longer maintained and may not work
properly. I don't think we should ignore bug reports on the old UI, but
they won't need a high priority.
As part of a new UI, I think that we should be careful to duplicate and
extend current *functionality*, but that we should not restrict
ourselves to making it look/feel exactly like the current UI. If a
redesign would work better, especially on mobile, then we should do that.
The current UI does work a lot better on mobile devices than the
previous UI. I avoided using my smartphone for even information
gathering because it was terrible. I don't have a tablet, but I think
that administration with tablets is becoming very common. My smartphone
is in the "phablet" category -- large screen with higher than HD resolution.
Thanks,
Shawn
Re: Next steps for Solr Admin UI - request for in-depth discussion
Posted by Jan Høydahl <ja...@cominvent.com>.
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 <uv...@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
Re: Next steps for Solr Admin UI - request for in-depth discussion
Posted by Upayavira <uv...@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org