bob2517
commented
3 years ago Not everyone is going to need PWA features, so either there will be a dedicated core for it, or I'll provide an expansion kit. A dedicated core is a better solution though, just from thinking about what needs to be available when an app is started up. Either way, I don't want to bloat the core with features if people aren't going to use them, hence a dedicated PWA version of the core.
A dedicated core would also guarantee compatibility between the main core and the PWA features, whereas two separate scripts, one for main core and one for PWA features, have the potential to be disconnected in version control by the developer, leading to unnecessary concern and confusion when the need to upgrade arises. A dedicated core it will be. I just need to keep backward-compatibility issues to a bare minimum.
I've got a potential large project coming up involving offline admin system requirements. Like filling out forms offline and then synchronizing when an internet connection is resumed. Using PWA technologies seems the obvious for this, as that is the native solution and is only going to improve over time, reducing the need for something like Cordova, Ionic, React Native, etc. Every framework has a fixed life-span, as the browser dictates functionality, not the frameworks, so using a framework doesn't make sense for a system that needs to last a couple of decades at least, if there is a native solution in existence. Every so often browsers improve, and then the framework devs need to upgrade their own systems to use the native browser technique, often introducing a different dev technique and a delay to ship, and that's not even getting into historically problematic device quirks and it's a bit of a faff and irritation to maintain and upgrade.
ACSS needs to work with native solutions, so there is scope to build-in all the web standard PWA functionality as it becomes available. ACSS appears a better solution than other frameworks, as it's ultimately mirroring native technology, offline apps work better in an SPA/event-driven context, and ACSS is an event-driven language. Event handlers are kept at a minimum in ACSS leading to better scalability and performance, it keeps getting optimized, plus the size of the code for a large component-driven SPA is smaller than comparable framework code. There's then flexibility to build a true mobile/desktop/tablet website. The only thing is native styling per device, but then that's more of a PWA issue and a lack of standardization of native CSS and core component code between platforms than anything I need to worry about in core design.
Certain PWA features appear to be common. The first one I'm looking at is network access. There needs to at least be a conditional in the core that can check network access. That would offer the most flexibility in handling forms and offer the ability to do something else if there isn't a network connection. It might not be the best approach - maybe the route is better to go via internal storage first always anyway and then sync when the network is there - but I need a place to start this adventure, and network connection seems a logical place to begin.
So the first step is:
1) Add a conditional for detecting if the person is online or not.