Dnn.React.Common Bundle Size is Very Large

[SkyeHoefling]

I was doing some research on building persona bar modules using the Dnn.React.Common npm library. It seems to include all the components or none of the components which increases the modules bundle size by 1,585 KB. I understand this bundle size is being used by admins with access to the persona bar so it isn't an incredible performance hit but it is still a performance hit. I took a look through the github issues and discussions and didn't see anything.

I am curious if anyone has looked into updating the webpack configuration to group the different components into separate files, or even npm packages. This would allow developers to utilize only what they need. Currently I have a react app that looks like this

import * as React from 'react';
import { PersonaBarPage, PersonaBarPageHeader, Button } from "@dnnsoftware/dnn-react-common";

import './App.css';

class App extends React.Component {

    render() {
        return (
            <div className="andrewhoefling-react-app">
                <PersonaBarPage isOpen={true}>
                    <PersonaBarPageHeader title="Hello World - React App">
                        <Button type="primary" size="large" title="Yes">
                            My Custom Button
                        </Button>
                    </PersonaBarPageHeader>
                    <div>
                        This is where the general body content will go
                    </div>
                </PersonaBarPage>
            </div>
        );
    }
}

export default App;

Note the 1 import line for everything Dnn React

import { PersonaBarPage, PersonaBarPageHeader, Button } from "@dnnsoftware/dnn-react-common";

I think it would be very useful if we could group this into 2 unique import statements

import { PersonaBarPage, PersonaBarPageHeader } from "@dnnsoftware/dnn-react-common/personabar";
import Button from "@dnnsoftware/dnn-react-common/button";

This would remove all other dependencies and only pull in the minimum required. An added bonus of this is any module that uses the Dnn.React.Common library would benefit from reduced bundle size.

Question

• Am I missing something with the organization?
• Was there a compelling argument to keep it all in one bundle?
• From my perspective there is no single persona bar module that will use every single component so it is wasting cycles downloading them and loading them into memory

[mitchelsellers]

FWIW recent discussions are that really React.Common should not be used outside of the actual PersonaBar/Internal to DNN Platform.

@david-poindexter or @valadas Correct me if I misstated that

[david-poindexter]

@ahoefling I understand exactly what you are saying. Let me give this a bit of thought. I would also like for @valadas and @mtrutledge to chime in on this as well. I am just not sure if it is important enough to have to rewrite the build process to split these apart for a handful of custom PB extensions. Also, all existing PB extensions use the bundle, so everything would have to be re-written just to support this splitting. Plus, I am not sure if the performance gain will be enough since they are already all being used by the collection of PB extensions. See where I am coming from?

[mtrutledge]

When we first started converting this splitting the bundles caused all sorts of issues to crop up. So we reverted back and just bundled it all into one. Over time the build process has changed a bit and no longer uses the React Common libraries from NPM. It was determined that only the Persona Bar should use the React Components. There are still some Persona Bar Extensions out there, but they are few. I don't believe the performance gain of splitting the files, in this case, is worth the effort, since the download only occurs when using the Persona Bar. Also, this download should only occur once, and the browser should then be able to fetch the cached version.

[valadas]

Yeah, in my opinion we should not recommend using it by 3rd parties. For one it is not great, for 2 we may have to do breaking changes in it very often and it would be a maintenance hell because the actual version loaded may not be the one that you reference.

[donker]

@ALL: Having worked on (and with) this here are my thoughts.

The bundle was made back in the day to centralize stuff for the PersonaBar. In the process they also made the React Common library available as an npm package so as to help 3rd party development. As we found out this wasn't without a few serious catches. For starters it was near impossible to develop the entire chain locally without going through some serious hacking to have the RC stuff compile and load for the various extensions. Secondly we discovered "hidden" integrations with other PB code (WebAPI endpoints, services framework, etc). It could have been much easier to spot this had the code been written in Typescript, but unfortunately it's not and so we are sometimes chasing rabbits throughout this maze of code. This means it is difficult to properly use outside of a PB extension (e.g. in a regular module). Finally we realized the headache of maintaining different projects with version numbers (npm vs our own Github releases). So we did two things:

1. We integrated everything into a single repository and unified version nrs, and
2. We vowed to stop promoting the RC library as something others should use as we felt it would be hard to support/guarantee future versions.

DNN has always had to make hard decisions about what to provide to developers and what to leave to them. The more we provide the easier it is to develop for DNN, but the more work we have maintaining code. If we ever offer components to developers, we should have those in a technology that is more future proof (minimally type safe I'd say), which is what some are working on.

The export bundle is there for the entirety of the PB. IMO we should leave it as it is and not aim to have each PB extension have its own version of various controls. Instead, if you're developing a PB extension and you use some of the RC components, you should keep an eye on that project. But for all other development scenarios it should IMHO not be encouraged to be used.

[SkyeHoefling]

Thank you everyone for the insightful responses, there is a lot to consider in what I proposed here. If I am understanding the consensus from here is the Dnn.React.Common npm library should not be used by 3rd party persona bar modules.

@mtrutledge

It was determined that only the Persona Bar should use the React Components.

@valadas

Yeah, in my opinion we should not recommend using it by 3rd parties.

@donker

The export bundle is there for the entirety of the PB

I've tried building a PersonaBar module without this library and I find the UX/UI is very disconnected from the rest of the Persona Bar modules. It is very easy to spot when a PersonaBar module was built using the Dnn.React.Common library and those that were not. While some of the styles might be loaded onto any PersonaBar page if you use webpack the library gets bundled with your bundle.js file which can be significant in size.

@mtrutledge

When we first started converting this splitting the bundles caused all sorts of issues to crop up.

I took a look at the Dnn.React.Common library today and I would agree with that statement. It appears to be very difficult to create smaller packages and the effort would be high.

I don't have a solution on this, but it may be useful for us to try and document some recommended techniques for building Persona Bar Modules. Publishing a simple list of what is okay for a persona bar module

• It is okay for a large bundle size since the persona bar is only compatible for desktop or tablet use (not sure if it supports tablets)
• It is okay to use Dnn.React.Common but there is no guarantee of stability from version to version

[valadas]

I've tried building a PersonaBar module without this library and I find the UX/UI is very disconnected from the rest of the Persona Bar modules.

So I am working on a new set of Dnn WebComponents, common stuff like buttons, inputs, search-box, tabs, and so on... The goals with this work are:

1. Can be used anywhere html can be used, so in the PersonaBar, in React, in Angular, in Webforms, MVC, name it.. Hell even in an html module.
   2 they will be super simple to use, something like

<dnn-tabs>
   <dnn-tab tile="Tab1">
      <p>Some normal html in here</p>
      <dnn-button type="primary">OK</dnn-button>
      <dnn-button type="secondary">Cancel</dnn-button>
   </dnn-tab>
   <dnn-tab title="Tab2">
      <div>Some more normal html here.</div>
   </dnn-tab>
</dnn-tabs>

3. They will also be distributed as javascript modules (npm and the likes) so someone using a javascript build system can also consume them.
4. They will inherit dnn styles... Everywhere, so same styles in an out of the PersonaBar.
5. Those styles will have some administrator changeable properties that will apply everywhere like primary-color, secondary-color, controls-radius.
6. Skin developers can further expand on those basics and it will apply everywhere it's consumed (as long as the theme can), this includes page content and custom modules that decide to use them.
7. They are super light-weight and lazy load just the used components, there is no framework other than a very minimal runtime that loads the components on-demand and wire up some events.

If this peaks your curiousity ping me up for a demo or take a look at https://github.com/eraware/dnn-elements where I am developing them until we get to 10

[thienvc]

I have been expecting this for a long time. Someone please come up with a common standard for DNN UI, because DNN's UI UX is so many years out of date compared to other platforms.
And one more thing, should we schedule the removal of jQuery from Core? I'm thankful for jQuery but the future trend I see is few platforms bringing jQuery to core.
Sorry my English is not good.

[valadas]

Unfortunately removal of jQuery dependency is not something we can just schedule, it is used in a ton of places, it is hard to figure out what may depend on it from 3rd parties, there is no great way to indicate it's deprecation to 3rd parties, etc.

For instance, the current ServicesFramework frontend implementation is a jQuery plugin, I did rebuild this small one on my personal projects to not rely on jQuery, but bringing that change into the core means all 3rd party calls to it will break. it's not an easy one and will probably need new names for things like ServicesFramework2 or StandardServicesFramework or some such, together with maybe browser console warnings to indicated to 3rd parties to use the new way, etc. This is one example out of maybe a couple of hundred places where that needs to be done.

But of course in anything new that at least I build, I try to avoid adding jQuery dependencies on them.

[SkyeHoefling]

This is really great and a wonderful effort to use stencil for native web components ❤

What can developers use today? What can be done to provide the right guidance? Should the npm package be deprecated and marked with a notice that it shouldn't be used? Should we no longer update it? I don't think we should ever take it down as developers are using it right now.

The fact is regardless what is decided in this discussion or in one of the slack groups people will still use the npm package for persona bar modules

[valadas]

Yeah, I think it would be a good thing to indicate that we don't recommend using it as we cannot respect our deprecation policy on it and it should be considered an internal Dnn package. I do have 2 modules using it and the client can't upgrade Dnn because of them. Adjusting those modules to the new package would require publishing new npm packages and then a lot of undocumented work to adjust them. I won't go that path and will just remove the dependency on it at some point.

What can developers use today?

Well a lot of bad things can be said about the Persona Bar, but one good thing it that it is really neutral on development. You just need html/css/javascript and then it is up to the developer. So Angular, React, Stencil, Typescript, plain old Javascript, you name it. Some of the modules in there just use html and knockout. Now for consistent look, well in 10 we will have those Webcomponents, I also plan to wrap some of those into the common bundle and the old UX/UI pattern so even old modules could benefit from that consistent look.

[thienvc]

I'm looking to change the way the PersonalBar looks (just change the way it looks - I don't like it always shows, I just want it to show a very small one and only show full on mouseover).
Does anyone know the fastest way? I plan to attach to the PersonalBar load or init event from my custom js, I don't want to modify the code directly into the PersonalBar. But I don't know if PersonalBar allows embedding customjs?

[valadas]

It is not a simple task, but if any effort is made to have it not always show (kinda docked), then it's important that the way to undock it is not only by hover.

I played a bit on trying to make it a drawer but ran out of time to make it usable and kinda had to switch gears into more important issues.

[thienvc]

I also know the difficulty, so I don't want to touch the core code of the PB, I just want to interfere with the external custom js.
I will try to see why because I am complained a lot by customers when after a user logs in, there is an 80px bar occupying the screen, causing the screen to skew very uncomfortable. Although the feature experience of the PB is very good.