In a world where add-on's will support more and more headless usage for Volto & co, how do we separate the existing Classic UI from the backend code and should we do it at all?
We have mainly 3 different parts here.
Backend code with the logic and data handling
Rest-API integration
Classic UI like views, viewlets, templates
Keep backend, Rest-API code and Classic UI together in on package
Move out Classic UI code into a separate package like collective.taxonomy.cui
0voters
I would like to find out how we want to handle this in the future and like to document this as a recommendation for add-on developers.
I think it depends. Having a single package can be easier to maintain. But if you want to stop supporting one side, you'll have to refactor the package, rather than just stop using one of the two.
I agree with @wesleybl in the point that it depends. When the classic UI code in the package starts to get in the way it's better to move out. That might be especially the case for more complex packages. The situation is maybe similar to archetypes and dexterity support in add-ons.
Personally I would keep everything together as long as it makes sense.
Having multiple packages also immediately increases the complexity and maintenance burden.
We have had somewhat choices/complexity the upgrade of add'ons from Plone 4 to Plone 5 where the 'frontend' resource setup also changed significantly from the old portal_css and portal_javascripts registries to the bundle system and require.js.
Try to keep everything in one package
Create a new 'major' release for Plone 5 only and keep the Plone 4 version support for a while or in maintenance/bugfix mode only
This only works if you can get rid of the old version support quick enough.
I have some client packages that work under Plone 4 and 5 but you REALLY have to know what you're doing. Especially the generic setup profile split was and is confusing, but also if you have 3rd party frontend libraries with js/css that you have to keep up to date.
But that's where the comparison ends because with Plone 4 -> 5 you still shared /duplicated the same (ZPT) templates and views in a server side system. From what I see now with Plone 6 headless the React frontend only needs the Content type definitions, permissions, behaviors etc server side. Everything else is not relevant and also not activated/triggered because you access/modify the data only through the REST API.
The bigger issue are secondary dependencies. If my current add'on uses Datagridfields, I'll have to pull in collective.z3cform.datagridfield on the server side, but that's adding complexit and posisble install issues without any of the frontend code in that package being necessary for headless.
Functional/design: all optional add'on configuration should always be exposed through Control panel Schema's stored in the configuration registry because Volto does already a good job to expose those panels automatically. Otherwise you have to tell people: noo but for this setting you have to go to the classic-UI website. No no no.
As @wesleybl writes 'it depends', the above are just other possible factors to add to the discussion, but it's rather tough to put objective weights to them.
My gut feeling to not have to clean up again in 2-3 years and have a 'clean cut' : same package name with major number in the semantic versioning.
Wouldn't it be a less confusing if new volto only (classic-less?) packages were named collective.mypackage.react or something?
Given the vast majority of existing packages are going to be classic and unlikely to want to change their package name even if they add plone 6 compatibility?
My 2c: we have had this use case for quite a while already. Here is what we usually do:
we add an "api" folder to the add on product and provide a REST API endpoint for the package functionality. This new endpoint can be used by both Plone Classic and Plone 6. If you create new functionality in Plone Classic, what worked for us in the past was to create a browser view with React.
we start to drop old functionality like Python 2 support, Plone 4.x/5.0/5.1 support (as soon as they cause trouble and/or too much work)
we drop Plone Classic support by removing browser views and stuff that we don't need any longer (as soon as this causes trouble and/or too much work)
for step 2 and 3 we create a major release, so that support for Classic and old Plone/Python versions is still available for people that need it. Anyone who has an interest or need to support old versions is free to do so. It is up to the package maintainer to decide what level of old cruft they want to support. If someone disagrees with that choice, they can always take over maintenance of the old branches and continue to support it, this is open source.
I successfully used this approach in plone.restapi (maybe not the best example), and all the collective packages that I maintain. I am strongly against creating Classic/Volto specific packages. That will confuse the hell out of people and we will end up with twenty different namespace approaches.
Each package is different and there might be use cases where a new package makes sense. Though, then just create a package with a different name and don't invent a new namespace. As a general rule of thumb, I would go with the semantic versioning approach outlined above. Semantic versioning is battle-tested, established in the industry, and well understood. Don't reinvent the wheel.