Package compatibility from V13 to V14
n
HI Matthew, It depends on what your package does, or in other words how much front-end code your package contains. C# code should be a walk in he park for the upgrade. but the front-end is a full rewrite. I hope that helps you make the decision 🙂
j
Hi @Matthew Alexandros , as Niels said, you could probably get around it if you were a bit cautious about your inner and outer elements, as in, if you built your UI with web components and wrapped them in an AngularJS layer, you could then remove the AngularJS layer in V14. As for C#, many of the APIs remain the same, but if you want to write custom API controllers, you will have to move the inheritance from
UmbracoApiController
to the native
Controller
from ASP.NET and implement the backoffice authorization policies, and on the frontend you would now authorize against an API using tokens (OpenID) instead of cookies, so you would have to add that to your Fetch calls or whichever client you choose on the frontend.
m
I don't think I would need to worry about Umbraco APIs. The intent is to read the appsettings json file for the Plausible API code and then make calls out to them toget analytics to display on the front end, probibily in graphs and such. So most of the work wouldbe UI based and from the sounds of it I might be better off waiting for v14.
n
Maybe, but notice, as Jacob mentioned. If you can succeed making most of your extension as Web Components or just Native JS (The inner parts). Then its only the integration/implementation that needs to be converted. 🙂
m
I am not familiar with Web Components or Native JS (I presume native is pure JS which means I just suck at it) Or maybe I will just pay someone to do the integration for me if this loto ticket I got is a winnner 😛
j
Lit with TypeScript is the way to go, you'll have most of everything you know from C# (and more) with TypeScript and lit makes it really easy to build web components
2 Views