Replies: 2 comments
-
|
Hey I've been thinking about this one myself, I really want to separate the Invoice Shelf into "Headless Core", and "Client(s)", so the user has a choice of how they wish to interact with the software, not just web. My vision is that with something like Expo and React Native that should be simple as we could build all Web, Android and iOS Native apps in a single repo since mobile web is basically just mobile version of the app. Web could also be compiled into a statically generated site, so we could simply bundle it with the Core as a "Core Client" which will utilise the same AIPs as the Android or say Desktop Native apps. This way user won't need to worry about any of the build processes, simply grab the latest release and run the app as we do now. I also strongly believe that Invoices/Estimates/Emails or any other type of user editable template should not live in the source code files and certainly not be part of the build manifest. Based on the git history it seems like a legacy solution that Crater had before which now doesn't really make sense. |
Beta Was this translation helpful? Give feedback.
-
|
I agree that separating the mobile app from the backend makes sense. However, considering that the entire application is already built with Vue.js, wouldn’t it be more consistent to stick with Vue.js for the mobile app as well? Perhaps we could explore using Vue.js with Tauri for mobile application to maintain coherence across the stack, rather than introducing React. What do you think? Regarding the build process, it's quite common to compile dependencies before pushing to the repository. This prevents users from having to host node_modules, which can quickly take up significant space. |
Beta Was this translation helpful? Give feedback.
-
Is your feature request related to a problem? Please describe.
The problem arises when users need to install all the dependencies locally and run yarn build to use the project. This can lead to increased storage usage on their servers, which is not ideal for those who want to save space.
This approach would also reduce the amount of support needed, as the project would be functional more quickly for users without requiring them to deal with the build process.
However, there is still the issue with templates that need to be re-built upon creation. It might be worth revisiting this system to address that particular challenge.
Describe the solution you'd like
I believe it would be more efficient to run yarn build before pushing to the repository. By doing this, we can avoid requiring users to install all the dependencies themselves, as they will only need the built version. This approach would save significant storage space on servers, which is especially important for large projects with many dependencies.
Describe alternatives you've considered
One alternative could be to let users handle the builds themselves after pulling the project, but this requires installing the entire set of dependencies. Another option would be to offer pre-built versions in a separate branch or release, though this adds additional complexity to the process.
Beta Was this translation helpful? Give feedback.
All reactions