Modularization of UI modules

[Ullrich Hafner]

Currently I’m using a lot of inline JS packages to provide a rich UI for the warnings plugin. I want to use the same UI modules in another plugin so I am wondering what would be the best way to provide these features.

Should I create a new API plugin for each of these dependencies? 

E.g. I’m using in warnings plugin 

- bootstrap 

- jquery 

And a lot more. Should I create one new plugin for each of those dependencies?

Then we have something like

warnings-plugin

+- bootstrap-api-plugin

\- jquery-api-plugin

and so forth… Or is this some kind of overkill?

How do we handle conflicts with Jenkins core UI packages? In Jenkins core we currently bundle some very old libraries that do not play nicely with my packages above. Should core get also some detached plugins for the UI part? E.g. in core we currently have hard-coded bootstrap 3 that is not compatible with bootstrap 4. In order to use bootstrap 4 in my plugin I need to replace the layout jelly tag with an individual version that does not load those problematic modules. 

[Jesse Glick]

On Tue, Jul 2, 2019 at 4:02 AM Ullrich Hafner <ullrich...@gmail.com> wrote:
> In Jenkins core we currently bundle some very old libraries that do not play nicely with my packages above. Should core get also some detached plugins for the UI part?

I do not think that is possible, as some of them are used in core
features like the Setup Wizard which cannot themselves be moved into
plugins.

Read

https://github.com/jenkinsci/js-libs

and you will know more than I.

[Ullrich Hafner]

> Am 02.07.2019 um 16:12 schrieb Jesse Glick <jgl...@cloudbees.com>:
>
> Read
>
> https://github.com/jenkinsci/js-libs
>
> and you will know more than I.
>

Yes, I tried to use that approach already without success. I got stuck somewhere in the middle and nobody is here who can help on UI issues anymore :-( Seems that all the UI super-heroes have left Jenkins...

[Jack Shen]

Hi Ullrich, you are not alone on this question, because I think we have some similar requirements on using external libraries. 

I'm currently working on my GSoC project, in which I tried using react with success. 

What we have done in the our plugin working-hours-plugin is integrating the file built by webpack into jelly file.

Actually, I has ever referred to the Warning NG Plugin, I agreed and learned some methods which you are using on fixing the incompatibility with prototype.js.

在 2019年7月3日星期三 UTC+8上午3:50:47，Ullrich Hafner写道：

[Jack Shen]

And I'm also wondering that would it be better if we switch to another solution like webpack? You know, using inline js libraries is not recommend in some conditions, so why not make some changes and try something new?

Jack Shen <angus0...@gmail.com> 于 2019年7月3日周三 19:33写道：

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/VOULzB0GozQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/18f2590a-7d65-4637-93af-c20accb02c5d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jack Shen]

For the idea that you had like a standalone plugin to provide dependency, I ever thought about that before.

However there might be too many dependencies and too many versions for each dependency. 

So I think maybe it's better to use a specific version of the library you use in your repo.

And if you are interested in the new way we're trying in working hours plugin, we could share some idea with you on each Thursday 13:00(UTC)

Jack Shen <angus0...@gmail.com> 于 2019年7月3日周三 19:38写道：

[Ullrich Hafner]

I’m not sure if we need so much new modules. For my plugin (and a lot of other reporter based plugins) I think it would make sense to have just a couple of them (<10). Bootstrap, jQuery, DataTables, ECharts, Prism, Fontawesome would be the prominent ones. The dependencies of e.g. bootstrap would make sense to be packaged into a bootstrap package. 

If I use individual versions per plugin then we get into problems if several plugins show up on the same page. E.g. the job or build page will be problematic (they are already since Jenkins core uses some old and not compatible libs here). I think here it would be much better if we have a set of JS plugins that would be shared by all plugins (and by Jenkins core). 

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPCUAQsvyCWF81HS%2B0bwrEnZdymoNkigeF8%3DBB_PZaJkUcsiGA%40mail.gmail.com.

[Gavin Mogan]

So I haven't had time to fully digest this thread, but a couple ideas/notes from me.

* Bootstrap and jquery are pretty large dependancies, are they needed for something specific? or just easier to do development. http://youmightnotneedjquery.com/ is kinda snarky and old, but does have some good points.

* if you use a bundler (rollup/webpack/Parcel/etc) + maven-frontend-plugin, you should be able to use npm install and requires, and not worry about other plugins are doing. Out f the box this has the disadvange of larger bundle sizes, but would reduce any friction. Its kinda what the java plugins are doing anyways, where they have seperate classpaths per plugin.

* Shared js deps is kinda how we got in the mess of having prototype on every page breaking things.

I know there's no up to date official browser matrix, but since plugins have a lot more flexibility when it comes compatibilty, my suggestion is to use more modern javascript and css, and not need all the frameworks that try to support the really old ones, or at least write modern code, but get babel to backport so it doesn't break old browsers, then we wouldn't need jquery as much.

Gavin

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/DD64433C-F29F-40BA-AB09-84BFD43208A6%40gmail.com.

[Ullrich Hafner]

Am 05.07.2019 um 00:07 schrieb 'Gavin Mogan' via Jenkins Developers <jenkin...@googlegroups.com>:

So I haven't had time to fully digest this thread, but a couple ideas/notes from me.

* Bootstrap and jquery are pretty large dependancies, are they needed for something specific? or just easier to do development. http://youmightnotneedjquery.com/ is kinda snarky and old, but does have some good points.

They are indispensable to provide a rich UI (tables, tabs, cards, grids, carousel,  etc) for plugins that implement the Recorder extension point. We already use it in Jenkins core, however, there we use some old and deprecated versions. 

* if you use a bundler (rollup/webpack/Parcel/etc) + maven-frontend-plugin, you should be able to use npm install and requires, and not worry about other plugins are doing. Out f the box this has the disadvange of larger bundle sizes, but would reduce any friction. Its kinda what the java plugins are doing anyways, where they have seperate classpaths per plugin.

Yes, I think that is the simplest way for plugin views. 

It just does not solve the problem on how to show rich UI elements on pages that are composed by elements of several plugins. E.g., I would like to show

- a badge with the number of warnings in a job link. This is quite easy using BS 4. However, core has a hard coded reference to BS 3 on the job page so it will not work.

- trends using ECharts. Since we have no support in core, every trend now needs to load the quite large trend JS. It would make much sense that the JS would be loaded only once on the page.

- responsive UI on the job and build page. On large resolutions only 20% of the page is actually used.

- ...

I think it would make sense to gather requirements for other plugins here as well. Then we finally should have a way in Jenkins core to provide some of these features. Otherwise one plugin is using echarts, the other plugin is using chart.js, and so on...

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DuvXki4OUu9AxXEmm8sB7JmRtGfMuvv4wby_UASqv%3D%2BqzA%40mail.gmail.com.

[Daniel Beck]

> On 2. Jul 2019, at 16:12, Jesse Glick <jgl...@cloudbees.com> wrote:
>
> Read
>
> https://github.com/jenkinsci/js-libs
>
> and you will know more than I.

There's also https://github.com/jenkinsci/js-samples which looks like it might be useful?

Step 4 looks potentially relevant?

[Ullrich Hafner]

Yes, I tried that last year. But I got stuck somewhere in between (see https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/jenkinsci-dev/1nb5UDiUjeI/h6f38kTiBgAJ). So I finally gave up since nobody was there to help. Also, looking at the commit history, it indicates that this approach is dead as well :-(

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/382F79BF-6618-4E97-8E1E-CA892BB0A381%40beckweb.net.

[Gavin Mogan]

I don't have fond memories of js-builder from working on blueocean.

Personally I still think larger bundle sizes for an app like this is fine, so using webpack or parcel or something to embed all the libraries you need directly will take care of the version problem.

If you have a simple web app, I can submit a PR or try to setup a sample plugin at some point.

https://parceljs.org/recipes.html will let you use commonjs, so its just requiring, no worrying about what other plugins are doing.

Gavin

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/3B172B21-751B-4660-8561-966B8C2CB15C%40gmail.com.

[Gavin Mogan]

https://github.com/jenkinsci/graphql-server-plugin/pull/4 is doing a wishlist item with parceljs

[Ullrich Hafner]

I just to report back here on how I finally implemented the modularization of the JS modules: for each JS dependency I created a new api plugin that contains the WebJar of the JS library and some utility classes. So other plugins can use these dependencies as well now. The resulting plugin dependencies are given in the following UML diagram: 

Legend: 

- blue: my plugins

- green: API plugins for JS libraries 

- yellow: standard Java library

I’m currently beta testing these new libraries, an example implementation is available in PR https://github.com/jenkinsci/warnings-ng-plugin/pull/252 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DuvnS%3DaNwvqYCpAXL1EaaS9CrTvFQKR2Xq3hXviGS2-Cfg%40mail.gmail.com.

[Ullrich Hafner]

As already mentioned in some previous threads, I extracted the UI components of the warnings plugin into separate UI plugins. So other plugins can easily use these components as well (without depending on the warnings plugin). The following plugins are available as beta now (a source code visualization plugin is still in the queue):

- https://github.com/jenkinsci/jquery3-api-plugin: jQuery is a fast, small, and feature-rich JavaScript library (Jenkins contains already an old version of this library).
- https://github.com/jenkinsci/bootstrap4-api-plugin: Bootstrap is - according to their self-perception - the world’s most popular front-end component library to build responsive, mobile-first projects on the web. 

- https://github.com/jenkinsci/data-tables-api-plugin: DataTables is a highly flexible JS library that enhances HTML tables with filtering, sorting, paging, and so on.

- https://github.com/jenkinsci/echarts-api-plugin: ECharts is a JavaScript visualization tool to create intuitive, interactive, and highly-customizable charts (on the client side).

- https://github.com/jenkinsci/font-awesome-api-plugin: Font Awesome has vector icons and social logos, according to their self-perception it is the web's most popular icon set with more than

1,500 free icons.

I’m using these components successfully in the warnings-ng and forensics-api plugins. If someone else wants to beautify a reporter plugin with these new components please let me know. It would make sense to have some more implementations using these plugins before releasing the 1.0 versions. (All plugins are available as beta in the experimental update center). 

I’m preparing a blog post as well, you can find the draft at https://github.com/jenkinsci/forensics-api-plugin/blob/master/etc/PluginGuide.pdf. Once the 1.0 release is done I will convert this draft documentation to a blog post (and plugin development documentation).

[James Nord]

I was looking at how old and outdated the junit test result charts looked next to you new charts.
ild love to try and update junit charts but that you is in the core so I feel this would be a step to far for my lack of frontend skills.

but amazing results!

[Ullrich Hafner]

I already thought about this as well. The JUnit plugin is not in the core anymore, or am I missing something? Or can’t the JUnit plugin depend on other plugins? Or are you referring to the large backlog of open PRs in this plugin that indicates that changes to that plugin should be done very carefully?

(Another much simpler option is to add such a chart in the warnings plugin that hides the orginal JUnit chart but that would be kind of hack...)

> --
> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/29e96d2f-b228-439e-8e5b-51141c679652%40googlegroups.com.

[James Nord]

> The JUnit plugin is not in the core anymore, or am I missing something 

Nope I am...

On Friday, January 17, 2020 at 6:35:23 AM UTC, Ullrich Hafner wrote:

I already thought about this as well. The JUnit plugin is not in the core anymore, or am I missing something? Or can’t the JUnit plugin depend on other plugins? Or are you referring to the large backlog of open PRs in this plugin that indicates that changes to that plugin should be done very carefully?

(Another much simpler option is to add such a chart in the warnings plugin that hides the orginal JUnit chart but that would be kind of hack...)


> Am 16.01.2020 um 22:36 schrieb James Nord <james...@gmail.com>:
>
> I was looking at how old and outdated the junit test result charts looked next to you new charts.
> ild love to try and update junit charts but that you is in the core so I feel this would be a step to far for my lack of frontend skills.
>
> but amazing results!
>
> --
> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to jenkin...@googlegroups.com.