Too many property-editors?

[leekelleher]

A couple of years ago, just before I started the Contentment package, I ran a Twitter poll.

As an #umbraco developer, would you prefer to install one big package with lots of features, (a la uComponents), or smaller packages with specific functionality?

• One big package (15.3%)
• Many smaller packages (84.7%)

Link: https://twitter.com/leekelleher/status/1080380092751200256

At the time, I had several prototypes of property-editors, some of these were inter-connected, (e.g. Notes used on various Data List sources), while others were standalone (e.g. Render Macro), and there was a bunch that didn't make it into Contentment.

The original (quick) Twitter poll had 85 votes, with majority saying that they would prefer smaller packages over one big package. I sometimes wonder if Contentment (in its current form) is "too big"? e.g. too many property-editors.

In chats I've had with various people over the past couple of years, the general response has been that Contentment is fine - Data List editor is the one they want, everything else is a bonus or ignored.

I'm 50/50 on whether there are too many property-editors in Contentment. Part of me wonders whether to spin off Data List to its own package. While another part of me thinks, whatever, let's add loads more property-editors to it!

I often get "developer itches", where I can knock up a new prototype property-editor. I end up creating a new branch, and then do nothing with it. Sometimes this feels like a waste, as it could be useful to someone out there. Examples of what I prototype.

• Dimensions, see "Dimensions" editor #1, (a height/width input)
• User Picker, see "User Picker" editor #2, (similar to Umbraco's old User Picker editor, but then I realised that a Data List with User data-source would be better)
• Transclude editor, see "Transclude" editor #5 (a textbox that accepted a URL and the ValueConverter pulled in the contents - in retrospect, it wasn't that good)
• Social Links / Social Picker, see "Social Links" (and "Social Picker") editor #8, (pick a social network icon, then enter the label/URL)
• URL Input, (a URL Picker type of thang, very basic)
• Macro Blocks, (same as Content Blocks, but only using Macros)
• Griddle, (a single column/area, lightweight version of the Grid)
• Duration, see Suggestion: Time Duration property editor #114, (@hfloyd suggested it, did a brief prototype, I didn't finish it)
• Inline Configuration Editor, (the UI for Data List's configuration, but inline instead of in the slide out panel)
• Cascade editor, see tweet for demo, (like the Enum data-source UI, but for any single-value property-editor)
• Wizard, (like Cascade, but sets of fields with prev/next pagination - the idea wasn't fully fleshed out)

Some of these may sound cool, others maybe not. But my point is, let's say that I had finished editors and added them to Contentment, would it feel overloaded?

How many property-editors is too many? 🤔

[hfloyd]

@leekelleher I think you and I had a separate chat on this topic several months ago, and if I recall correctly, where I personally came down on the issue was two-fold:

1. Having to update a single package is easier than having to manage/update multiple smaller packages (though, reflecting further, I can see the opposite side as well - multiple editors in a single package might mean more releases (as individual editors might get a fix/enhancement, causing a package release)
2. This is YOUR project, and you have generously donated a huge amount of time to it, and we all benefit, so you should get to decide how YOU want to manage things - it is easier or harder for you to have multiple repos/packages?

The methodical list-making part of me says:
What are the Pros/Cons of single versus multiple packages?
This would be from the git/dev management side, as well as the technical side. Are some editors interdependent? Is there any real downside to having extra Property Editors installed/available in an Umbraco install, even if they won't be used?

[leekelleher]

re: pros/cons - the main concern (from people I've chatted with) is that they feel have more property-editors installed than they use is wasteful. Leaner to only install the editors that are going to be used.

Side-note, in terms of overhead, the unused property-editors would be added to Umbraco's internal caches for PropertyEditorCollection, and any CSS and JavaScript assets would be loaded into the backoffice.

I can see their point, but at the same time, I tried that with my Umbraco v7 packages and I ended up doing more support work. 😬

It's easier for me to do it all in one big package. But yes, like you say, if there's a bug fix to a single editor, it will need a full package release.

[hfloyd]

Well, if that's all we have to add to the lists... then I think single-package wins. 😉

[hfloyd]

Pros/Cons: Single Package

Pros:

1. Single GIT Repo / NuGet package for Lee to manage (less support work)
2. Devs using multiple editors only need to install/update a single package.

Cons:

1. Unused property-editors would be added to Umbraco's internal caches for PropertyEditorCollection, and any CSS and JavaScript assets would be loaded into the backoffice.
2. There will be more releases of package updates, even when fixes are provided for editors the Dev isn't using.

[DanDiplo]

I think we could all come up with pros and cons, but ultimately I'd say just do whatever is simplest and easiest for you to maintain. It's a superb package!