Gus, sorry for the delay. I did not see this email probably because of a draft. There is module loader known as Webpack that has a feature known as Hot Module Reload that enables hot reloads and preserves state when most changes are made. It can be used with any framework. See here: https://webpack.js.org/concepts/hot-module-replacement/
For vue, there is the vue-cli, the equivalent of Angular CLI that provides ng serve. https://vue-loader.vuejs.org/guide/hot-reload.html#state-preservation-rules For React, there are many options for enabling hot reload. Thanks Gus, Marcus On Mon, Apr 27, 2020 at 6:26 AM Gus Heck <gus.h...@gmail.com> wrote: > From this one article (probably should read several) angular has a higher > learning curve, but a better tooling system, and is better for a one-page > app style - from the descriptions I tend to suspect there's also a greater > chance of react/vue turning into mush in the hands of less experienced UI > developers... perhaps more rope allowed? Just an impression though. So > perhaps one of the first things to consider is do we expect to build it as > a single page or multi-page app? > > One Q for anyone who has used them: does react or vue have the equivalent > of ng serve? It's nice to be able to iterate the ui quickly. That's one > thing I do like about it. > > > https://www.udemy.com/blog/react-js-vs-angular-vs-vue-js-which-is-the-best-javascript-framework/ > > -Gus > > On Thu, Apr 23, 2020 at 3:27 PM Marcus Eagan <marcusea...@gmail.com> > wrote: > >> Jan, I think this is a great option. Angular's future is probably < 5 >> years. More and more people move to React and Vue every day it seems. Very >> occasionally, people move to StencilJS (which we should avoid like the >> plague). At least, thee insights are what the market and my friends tell me. >> >> thanks, >> >> Marcus >> >> On Thu, Apr 23, 2020 at 1:06 AM Jan Høydahl <jan....@cominvent.com> >> wrote: >> >>> The old UI is not perfect, and it cannot do everything, i.e. you cannot >>> choose replica types when creating a collection, it has no support for >>> authoring Autoscaling rules, no support for doing backup/restore etc. The >>> dream would of course be that the new UI is so sweet to work with that >>> almost any new feature added to the backend also gets a simple UI >>> component, if not in the same release or by the same developer, then at >>> least a release or two further down the road. >>> >>> Why I put the three github links in this thread was not because it is a >>> thorough survey of everything that is out there. It was 30min search on >>> github just to find prior art. I expect whoever drives the SIP work to do >>> even more thorough investigation as to what our options are. Not being a >>> full-time frontend engineer, I cannot speak for Angular’s future. It would >>> of course be a pity if we choose the framework that happens to be the next >>> one to go extinct :) so Vue feels more secure than Angular but what do I >>> know? >>> >>> Finally, I hope the SIP, in addition to surveying existing code and >>> possible frameworks, should also list the deployment options we have (jetty >>> inside solr app, jetty separate webapp, jetty, different port, standalone >>> node, package system…), and recommend one. Perhaps lay out a roadmap >>> starting with drop-in replacement as first step? >>> >>> >>> When it comes to the question of covernance and where the code lives, I >>> came to think of another option we have not yet discussed. It goes like >>> this: >>> >>> Solr Admin UI could be another sub project of Lucene/Solr, as PyLucene >>> is, with its own git repo and its own releases. >>> The release would be a ZIP with the compiled UI and instructions on how >>> to deploy as part of Solr or standalone. >>> Then Solr core build would pull in the zip as a dependency and serve it >>> up as today or in a new way. >>> Benefits of this solution includes: >>> + The core codebase remains Java only (with versioned UI as dependency) >>> + The UI is still governed and released by the project >>> + The UI gets its own repo, and its own GitHub home, which can maybe >>> easier attract PRs from newcomers? >>> + UI can do releases out-of-band. Solr can stay on same UI-release for >>> several versions if it wants, and we can publish UI-only bugfixes for XSS >>> or whatever, with easy patch instructions >>> + End users may choose to disable UI in solr.in.sh and deploy the UI >>> release standalone, i.e. more choice >>> The downsides are of course >>> - More moving parts, separate releases, more bureaucracy >>> - May be a problem to obtain enough PMC members vote (ask Andi), need a >>> separate smoketester? >>> - UI is not tested as part of Solr, breaking changes may be merged >>> unnoticed. (This can be mitigated with e2e Jenkins tests) >>> >>> There may be downsides I have not thought of, but interested in your >>> thoughts >>> >>> Jan >>> >>> 22. apr. 2020 kl. 18:54 skrev Marcus Eagan <marcusea...@gmail.com>: >>> >>> Nothing is ever finished. >>> >>> Yet I agree with you one hundred percent. I don't like the idea that you >>> can delete a collection from the UI, but that's just me. I didn't want to >>> get in to the discussion until I was further along. >>> >>> Marcus >>> >>> On Wed, Apr 22, 2020 at 9:50 AM Gus Heck <gus.h...@gmail.com> wrote: >>> >>>> Re Parity: If we are going to drop a feature from the UI it should be >>>> an explicit decision to do so. I think until we have either >>>> >>>> 1) a decision to drop (expressed in the SIP or Jira) >>>> 2) a working re-implementation >>>> >>>> For each feature the new UI should not be considered finished. >>>> >>>> >>>> On Wed, Apr 22, 2020 at 12:14 PM Marcus Eagan <marcusea...@gmail.com> >>>> wrote: >>>> >>>>> Parity is not necessarily a good thing. Maintaining most of the >>>>> existing functionality is good. I would recommend some of it is removed >>>>> because it’s dangerous. >>>>> >>>>> My choice to pick up the project I did was because it was the most >>>>> updated of them all and I can change one variable rather than multiple >>>>> because the Angular name was the same. >>>>> >>>>> Thanks Jan and Houston. I need to try the project out later tonight. >>>>> >>>>> I’m happy to contribute to any of them. >>>>> As for the test, the scaffolds are the first step to adding tests. >>>>> They can be added relatively quickly but even the scaffolds ensure the >>>>> components compile, which is step forward for the project where it is >>>>> today. There are a couple months of work on it. I did not intend for >>>>> anything to be merged yet, but for code to exist for people to test it >>>>> out. >>>>> >>>>> The Angular project is a pain. However, I will keep the project up >>>>> and work to support whatever the community needs. >>>>> >>>>> My goal is to get an updated Solr Admin UI Im the project to help >>>>> developers get started, and improve security. Whichever one the community >>>>> decides on, I will work with everyone to help get it done. >>>>> >>>>> Thank you, >>>>> >>>>> Marcus >>>>> >>>>> >>>>> On Wed, Apr 22, 2020 at 08:24 Houston Putman <houstonput...@gmail.com> >>>>> wrote: >>>>> >>>>>> I agree with Jan, I think we need some discussions on alternatives >>>>>> and the pros/cons of each before we invest in implementing a solution. >>>>>> >>>>>> I personally have the most experience with React and don't know much >>>>>> about other frameworks, but I'd love to understand why Angular or Vue.JS >>>>>> might be a better option. >>>>>> (Having an implementation to start with is definitely a plus, and it >>>>>> doesn't look like there is one for React) >>>>>> >>>>>> Yasa looks more complete than savantly-net/solr-admin to me, and >>>>>> definitely warrants at least a look. >>>>>> >>>>>> - Houston >>>>>> >>>>>> On Wed, Apr 22, 2020 at 7:27 AM Jan Høydahl <jan....@cominvent.com> >>>>>> wrote: >>>>>> >>>>>>> I spun up the proposed app for the first time today, clicked around >>>>>>> and browsed the code. >>>>>>> It appears to me that the app is far less developed than I thought, >>>>>>> which agrees well with only 12 commits. >>>>>>> The collections component only knows how to list collections, the >>>>>>> «create collection» button is dead etc. >>>>>>> It will be a HUGE effort to bring this to feature parity with >>>>>>> current AdminUI. >>>>>>> I cannot find any substantial tests other than scaffold tests >>>>>>> verifying that ng components are created ok. Could be because there is >>>>>>> not >>>>>>> that much functionality to really test yet? >>>>>>> >>>>>>> Which makes me question again the perhaps premature decision on >>>>>>> using this repo as a basis. >>>>>>> >>>>>>> >>>>>>> So I did a quick test with the VueJS based YASA app ( >>>>>>> https://github.com/kezhenxu94/yasa) and got up and running in a few >>>>>>> minutes, with a much more feature complete UI. >>>>>>> It is also a complete drop-in replacement for the old UI, once >>>>>>> compiled. Downside is that it is older and needs upgrade and to play >>>>>>> well >>>>>>> with CPF. >>>>>>> So let’s step back for a while and not make hasty choices too early. >>>>>>> I worked with VueJS in a project and really like it. Vue is the 2nd >>>>>>> coolest >>>>>>> kid on the block after React >>>>>>> according to https://2019.stateofjs.com/front-end-frameworks/ and >>>>>>> Wikipedia just chose it over React for their UI makeover. >>>>>>> >>>>>>> Anyway, if you want to test YASA locally, here is a 3 minutes recipe >>>>>>> for doing so: >>>>>>> >>>>>>> https://gist.github.com/janhoy/0f7cddc0d92f9e53db7522fe93ff7003 >>>>>>> >>>>>>> To me, this looks like a much better starting point, and the project >>>>>>> has 2x the contributors, 3x the commits and a MIT license :-) >>>>>>> >>>>>>> Another reason to spend more time in SIP mode, iterating on what is >>>>>>> best for the project, what alternatives were considered and why certain >>>>>>> frameworks were selected/rejected etc etc, before spending much more >>>>>>> time >>>>>>> coding. >>>>>>> >>>>>>> Jan >>>>>>> >>>>>>> > 22. apr. 2020 kl. 11:30 skrev Noble Paul <noble.p...@gmail.com>: >>>>>>> > >>>>>>> > As I see it all the 12 commits to that project is made by Jeremy >>>>>>> Branham. >>>>>>> > >>>>>>> > Kudos to Jan Høydahl to save Solr from potential lawsuit & >>>>>>> > embarrassment in the future. Awesome, I guess you are a part time >>>>>>> > private detective >>>>>>> > >>>>>>> > On Wed, Apr 22, 2020 at 7:25 PM Ishan Chattopadhyaya >>>>>>> > <ichattopadhy...@gmail.com> wrote: >>>>>>> >> >>>>>>> >>> The shoulders of the homie that put that scaffold together are >>>>>>> broad! Props to him. >>>>>>> >> Marcus, are you working with Jeremy Branham on this? >>>>>>> >> >>>>>>> >> On Wed, 22 Apr, 2020, 2:25 pm Jan Høydahl, <jan....@cominvent.com> >>>>>>> wrote: >>>>>>> >>> >>>>>>> >>> WRT legal aspect, the original git repo >>>>>>> https://github.com/savantly-net/solr-admin does not say anything >>>>>>> about copyright or license. I encourage you to reach out to the >>>>>>> copyright >>>>>>> holder to let them/him know about your intentions and get a temporary >>>>>>> OK. >>>>>>> They may later need to sign a code grant (SGA) in order for the project >>>>>>> to >>>>>>> legally integrate the code. >>>>>>> >>> >>>>>>> >>> Jan >>>>>>> >>> >>>>>>> >>> 22. apr. 2020 kl. 07:42 skrev Mike Drob <md...@apache.org>: >>>>>>> >>> >>>>>>> >>> In phase 2, will the admin ui be running in the same jetty >>>>>>> container as the solr application? >>>>>>> >>> >>>>>>> >>> On Mon, Apr 20, 2020 at 4:35 PM Marcus Eagan < >>>>>>> marcusea...@gmail.com> wrote: >>>>>>> >>>> >>>>>>> >>>> SIP here: >>>>>>> https://cwiki.apache.org/confluence/display/SOLR/Updated+Solr+Admin+UI >>>>>>> >>>> >>>>>>> >>>> On Mon, Apr 20, 2020 at 9:32 AM Gus Heck <gus.h...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>> >>>>>>> >>>>> If Marcus has ability to edit existing pages, why don't we >>>>>>> create the empty page for him and sort out access granting issues later. >>>>>>> I'd hate for this much needed SIP to bog down on a technical issue. >>>>>>> >>>>> >>>>>>> >>>>> -Gus >>>>>>> >>>>> >>>>>>> >>>>> On Mon, Apr 20, 2020 at 7:10 AM Jan Høydahl < >>>>>>> jan....@cominvent.com> wrote: >>>>>>> >>>>>> >>>>>>> >>>>>> Please retry. I gave edit access to confluence user id >>>>>>> ‘marcussorealheis’. >>>>>>> >>>>>> >>>>>>> >>>>>> Jan >>>>>>> >>>>>> >>>>>>> >>>>>> 20. apr. 2020 kl. 01:30 skrev Marcus Eagan < >>>>>>> marcusea...@gmail.com>: >>>>>>> >>>>>> >>>>>>> >>>>>> I do need help. I am not allowed to create a SIP. Or, I have >>>>>>> been unable to create a SIP in three previous attempts. >>>>>>> >>>>>> >>>>>>> >>>>>> Marcus >>>>>>> >>>>>> >>>>>>> >>>>>> On Sun, Apr 19, 2020 at 3:45 AM Jan Høydahl < >>>>>>> jan....@cominvent.com> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks. The PR is useful for people to try out the UI. But >>>>>>> for overall replacement plan I really think we neeed that SIP, do you >>>>>>> still >>>>>>> need help with Confluence? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Jan Høydahl >>>>>>> >>>>>>> >>>>>>> >>>>>>> 19. apr. 2020 kl. 06:30 skrev Marcus Eagan < >>>>>>> marcusea...@gmail.com>: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I hope everybody is enjoying their weekend and is in good >>>>>>> health. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Filed a Jira, made a PR: >>>>>>> https://issues.apache.org/jira/browse/SOLR-14414 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Still, quite a bit more work to do. I need to spend some >>>>>>> time on the query screen, improving the cluster view, and adding alias, >>>>>>> and >>>>>>> more tests. The last three should be pretty easy. Would probably spend a >>>>>>> couple weeks working on style as well, but that can be an ongoing >>>>>>> effort, >>>>>>> just as making it package manager compatible and using v2 commands. >>>>>>> There >>>>>>> are also many areas where the Use of TypeScript or the Angular framework >>>>>>> will improve. That will come with time, some involvement from a few >>>>>>> Angular >>>>>>> wizards, and a bit of research. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thank you everyone, >>>>>>> >>>>>>> >>>>>>> >>>>>>> Marcus >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Apr 14, 2020 at 2:01 PM Marcus Eagan < >>>>>>> marcusea...@gmail.com> wrote: >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> Gus, At first it looked like it let me, but today it seemed >>>>>>> that it did not allow me to create a SIP. >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> On Tue, Apr 14, 2020 at 8:57 AM Gus Heck < >>>>>>> gus.h...@gmail.com> wrote: >>>>>>> >>>>>>>>>> >>>>>>> >>>>>>>>>> First, sorry you’re having problems with Confluence. I >>>>>>> suspect the issue is permissions. There are only two groups allowed to >>>>>>> add >>>>>>> pages to the SOLR space, “lucene” and “lucene-pmc”. I believe these >>>>>>> correspond to ASF LDAP groups, which would mean they include committers >>>>>>> and >>>>>>> PMC members only. We can grant you individual permission to add/edit >>>>>>> pages, >>>>>>> however; we’ve done this for a handful of others. I could do this for >>>>>>> you, >>>>>>> just ping me off-thread so I can confirm your username. >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> If that is the issue, then we should advertise clearly on >>>>>>> the SIP page that non-committers wishing to create a SIP should request >>>>>>> access on this list. That's probably a good mechanic because it ensures >>>>>>> that contact with this list is established first. And it sounds like >>>>>>> confluence is allowing him to start editing and then throwing away all >>>>>>> his >>>>>>> work on submission which is VERY bad behavior... Possibly an INFRA >>>>>>> ticket >>>>>>> if that is indeed the case... >>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> @Marcus can you confirm that you tried to create a page, >>>>>>> it appeared to let you and then threw out your work on submission? (or >>>>>>> am I >>>>>>> reading what you wrote wrong?) >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>>> -- >>>>>>> >>>>>>>> Marcus Eagan >>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Marcus Eagan >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>> -- >>>>>>> >>>>>> Marcus Eagan >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> -- >>>>>>> >>>>> http://www.needhamsoftware.com (work) >>>>>>> >>>>> http://www.the111shift.com (play) >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> >>>> -- >>>>>>> >>>> Marcus Eagan >>>>>>> >>>> >>>>>>> >>> >>>>>>> > >>>>>>> > >>>>>>> > -- >>>>>>> > ----------------------------------------------------- >>>>>>> > Noble Paul >>>>>>> > >>>>>>> > >>>>>>> --------------------------------------------------------------------- >>>>>>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>>>>> > For additional commands, e-mail: dev-h...@lucene.apache.org >>>>>>> > >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>>>>> >>>>>>> -- >>>>> Marcus Eagan >>>>> >>>>> >>>> >>>> -- >>>> http://www.needhamsoftware.com (work) >>>> http://www.the111shift.com (play) >>>> >>> >>> >>> -- >>> Marcus Eagan >>> >>> >>> >> >> -- >> Marcus Eagan >> >> > > -- > http://www.needhamsoftware.com (work) > http://www.the111shift.com (play) > -- Marcus Eagan
