Hey, I own an agency and we specialize in creating weweb apps.
First of all, we all love weweb and its an amazing tool!
Although, one of the annoying aspects is working with multiple devs on the same project.
We have a QA person that tests all of the completed tickets on our staging environment. What happens sometimes is, one dev finishes something and is ready to publish his changes, whereas the other is in progress.
This creates a problem where the staging environment might have changes from multiple developers at a time, not all being fully completed and some causing bugs/preventing testing.
We of course can mitigate this issue with proper communication, but ideally we could create âfeature branchesâ for each ticket and merge them up the chain separately.
Is something like this possible/on the roadmap in the near future?
Itâs something the product team is thinking a lot about these days. They are currently exploring different options to handle the versioning of components and design systems which they expect will do a lot of the heavy lifting. Canât yet communicate an ETA because there are a couple of UX design challenges they want to nail before starting development work.
As Joyce mentioned, this is something we are working on. Hereâs a preview of whatâs coming:
Project Versioning and Rollback
You will be able to commit your work, with auto-commits occurring at regular intervals. This ensures that your progress is regularly saved as a new project version.
You will have the ability to roll back the editor to any previous version, preventing any potential loss of work.
Additionally, youâll have the option to launch any version in a read-only mode, useful when collaborating with others who have also made changes.
It will be possible to copy and paste content from any version in the history.
However, please note that creating branches and merging them wonât be available initially. Weâll revisit this later. Iâll explain why below.
Revamping Design System with Version Control
Design systems will now be managed at the project level rather than the workspace level.
To update a design system, youâll need to edit the respective project, similar to how you work with a Figma file.
Once updated, you can share and publish these design systems within your workspace.
For example, you can create a project named âMy Kit,â where you define colors and a class called button. You can then share and publish this design system.
In another project, say âProject B,â you can include âMy Kitâ and use the button class.
Changes made by a collaborator to the button class in âMy Kitâ wonât affect its value and usage in âProject Bâ until the collaborator publishes a new version.
You will have a notifications in âProject Bâ and decide whether to adopt the latest version, including the ability to test and use a previous version if there are any breaking changes.
As a side note, we might rename design systems to Libraries.
Components with Version Control
Youâll have the capability to create components within the editor, allowing for the reuse of logic and easy maintenance of instances.
Components can include local variables, local workflows, props, drag-and-drop zones, and the embedding of other components.
Similar to design systems, youâll need to publish every change made to components.
Components will also be integrated into design systems, giving you control over which version is active in various design system versions.
We believe that these version control features are the initial steps toward branching. They are essential for effectively scoping collaboratorsâ work and ensuring maintainability and scalability. These measures will minimize conflicts when merging potential branches, which is a significant challenge when dealing with branching, especially in a no-code environment where you canât simply update a single line of code. You have to decide who wins.
Our plan is to release project version control and design system revamping in October, followed by components in November. Branching will be introduced later in 2024 after we have refined our version control capabilities sufficiently.
Hey @flo, thank you for answering! Very excited about the upcoming features, cant wait!
Once we have components, versioning and all that I think weweb will be the greatest no-code tool on the market by a big margin (in my book it already is due to the customizability aspect)
I will be happy to participate in a beta with our agency www.natural.agency for any of the features
Hi Flo,
I wonder what the status with Version Control updates is?
Itâs been a while. We are waiting for it very much, because it actually would make the collaborative work of several developers on one project way more easier (right now itâs really stressful when it comes to control of changes).
Hi @flo is there any update on when this released? I run a Bubble agency and the main thing preventing us from using WeWeb is that we do not have branches, this is important when working with a production app or with several developers.
Apparently theyâre focusing on AI features at the moment. I understand why theyâre doing it from a marketing perspective, but dang, there are so many other more important and useful features to implement. Features like this.
I think youâre as delusional as the others if you have this narrow AI being the only thing that makes a company stay afloat mentality. Welcome to the community, try to not be a dick. Why the hell are you even in a no-code toolâs community talking shit if no-code is obsolete?
It could be a sad time for WeWeb if the AI update brings toxic people like you @sproutsdev
100% with @Broberto. @allisonâs follow-up question is a very valid one. As I understand this is on the roadmap of 2025. @carrano_dot_dev AI is âhotâ - but there is true power to it. Something to be leveraged on features in the sphere of collaboration (such as branching).
Iâm definitely not saying AI isnât powerful/useful. I use it everyday and I use Chatgpt in conjunction with Weweb for things like writing scripts and brainstorming architecture. I even studied it well before all this LLM craze. I just think that at the current state of AI, a more involved integration with Weweb wonât have a very profound effect from a dev perspective. Iâd imagine it would mostly help beginners.
Additionally, if AI gets to the point where it is useful for experienced devs using Weweb, devs and Weweb alike could face obsolescence. Under those circumstances, any effort put into tighter integration might prove futile in the long run.
