DNNDocs
DNNDocs copied to clipboard
DNNCommunity
Feedback for Site Groups
Should this one still be present? I mean AFAIK there is a Sitegroups module from some time ago but that's it...
[Enter feedback here]
Document Details
⚠ Do not edit this section. It is required for dnndocs.com ➟ Core Team processing.
- Content Source: site-groups
@SCullman published this module to manage site groups https://github.com/SCullman/Connect.Sitegroups there is one published release and it looks like he is working on a 9.3+ compatible release. I would help if we want to merge this module into the platform so we can maitain it with the others. Ping me up if you need help @SCullman
Yes, I tried to setup a 9.3+ compatible release.
I am still failing, and I have no glue how to fix that. While I am still waiting for new npm and nuget packages, I am now aware that this doesn't help, as I complied them on my own.
I don't have time to fix that and I spend already too many hours on that. I don't feel good in doing a PR with code that doesn't run. Anyway, if you want me to do that, and somebody cleans up afterwards, I will do.
I am curious, are there any other PersonaBar modules outside of DNN which suffer the same?
I don't have time to fix that and I spend already too many hours on that
I can offer help if you need to fix stuff and then submit it or I could handle that alone probably much farther in the future, I have a looooong backlog here :)
I am curious, are there any other PersonaBar modules outside of DNN which suffer the same?
Kind of... So the story is that PersonaBar modules are not tied to any particular technology, it just uses normal html/css/js. Then developers are free to use any framework or no framework at all to build the innards. That is the good part.
The bad part in my opinion is that the Dnn common components package was wrapped all into one bundle that includes React too. Not too bad if only Dnn uses it, since we know about it and can update everything at onces on updates of dependencies. But what really hurts is that it was suggested to developers to use those common components, which puts us in a corner. We need to bump versions often but that also means developers that decided to use them also need to do so. There is no way we can apply the same deprecation policies as in the platform because first there are a gazilion of denpendencies and sub-sub-sub-sub dependencies, they evolve wayyyyy to fast to only bump them on major releases. The bad bad bad part is that React also makes breaking changes way too often, sooo yeah a developer that opts in consuming the bundle kind of also opts in doing much more frenquent updates than only on major Dnn releases.
Well, then, if there is no one else who steps int, we will wait and see what happens in the future. I have written that module already three times in different styles, and maybe I give it a try as part of an upcoming Dnn.Fable toolkit.
The bad part in my opinion is that the Dnn common components package was wrapped all into one bundle that includes React too.
Does it? React and React.Dom are only listed inside devdependencies.
The bad bad bad part is that React also makes breaking changes way too often, sooo yeah a developer that opts in consuming the bundle kind of also opts in doing much more frenquent updates than only on major Dnn releases.
Well, I am doing a lot of stuff sitting on top of on React over the last two years . Looks like the F#/Fable stack is protecting me. But I just did a search for 'componentWillMount' and I can feel your pain.
Does it? React and React.Dom are only listed inside devdependencies.
Yeah, kinda, what the common bundle exports (webpack externals) is this https://github.com/dnnsoftware/Dnn.Platform/blob/development/Dnn.AdminExperience/Dnn.React.Common/WebpackExternals/index.js
So when you import the bundle, your code expects all this to be present on the page already and consumes those. So you kinda need everything to be on the same version or at least a non-breaking changes version compatible.
What the hell is window.dnn.nodeModules.React? Why?
That's terrible.
IMHO each Persona Bar module should be treated as its own SPA with its own dependencies.
How cares for an Persona Bar app when it is not optimized for size?
yeah, the idea was that each module could be smaller by not having to include React and the common components on each. But that ended up being a maintenance nightmare and should have never been recommended for developers to use in their own modules. But well, this is where we are now and it will take a lot of efforts to restructure that. At least the merged repositories makes it a bit easier to maintain now, so looking forward to improving that...
This being said, a developer does not have to take the common bundle, the persona bar supports any html/js/css content and any framework or no framework in the modules. Some of the simpler ones are just html and knockout for binding.
so would this feature work best trying to make it with HTML JS and CSS to keep it from breaking down the road? Just wondering if any luck with this as I can see a lot of bummer about React.
Is there some sort of basic persona bar template that shows basic usage of updating the db and viewing?
https://github.com/dnnsoftware/Dnn.Platform/issues/2745 This is the latest issue related to Site Groups. Currently after version 9.5 release Site Groups can then be looked more closely into finishing up the issues currently with adding @SCullman module Site Groups settings UI to the persona bar.
Yes, we have been working a lot on the build process and are now setup to start republishing than component. When 9.5.0 is out we will be able to recompile that module quickly probably without too much trouble.