Expanding on this point of focus…
Among other reasons, this pushes me to use libraries. If I have an action with more than a dozen actions, I start thinking about converting them to a library.
So the requests for an easy way to do this (like creating a partial) might get people to create more modules. I do it via code view, but that is prone to errors and takes time.
It is amazing how breaking your code into chunks can enhance readability and long term management.
After I started doing this management of my server actions became much easier because I did not have to scroll miles. If I had all the execute library actions in on action, this would be a nightmare:
Each of these are maybe screen height in length. Even they could be broken into smaller “functions” or server actions.
@George Would it be possible to add a “quick link” to the specific library action you are using in the execute step? So when you click the step it opens in new tab to edit. This suggested workflow would help many with longer server actions.
If I have an action with more than a dozen actions, I start thinking about converting them to a library
Ken, my app has some complex algorithms which would become a nightmare to develop if I had to break them into such small pieces and pass the data around between library elements…
We are all developing such different things and need the tools to manage whatever those are, which has always been the beauty, strength and power of Wappler so far!
I’m not a CompSci major, so I’ve got nothing to stand on but my experience, so I’ll just strongly disagree. 
I see where you are coming from on that one Ken.
When i wrote the API action i showed in earlier post, libraries had not been added to Wappler.
I still stand by my opinion that a CASE statement would make a lot of these API actions more streamlined
Also perhaps a mechanism to house sections of code within a “container” which served as nothing more than a collapse for visual purposes so the actions could be more easily broken down into modules (if library actions were not appropriate), a bit like how many use the html [section] to modularise the code in the app panel
Yes, currently you can drag as long as there is something to scroll. if it all fits in the current canvas - then there is no need to drag/scroll.
Another interesting factor in this for me is where you work.
I’m a bit of a digital nomad, and I can’t be taking a monitor everywhere I go, so being able to work comfortably on one medium sized laptop screen is important for me…
We are all soooo different! 
I have tons of these. I just try to “fix” them when I’m making modifications. Constant evolution. This is the nature of development.
Absolutely
Perhaps. But that is what an include/exec does as well. I wouldn’t use it, but if it makes others happy, it won’t get in my way.
Definitely a topic for another major improvement: keeping the front end organized and well commented in the editor, without pushing a bunch of bloat to production. Probably not for v6, but you never know!
Just released beta 5 with some last minute fixes, specially the multi line comments for @TomD
In a canvas, all actions flow from top to bottom. However, I thought it might actually be better to be able to use the canvas as we wish, that is, to be able to drag and drop actions as we like (although I’m not entirely sure).
Also, the spaces between actions and within them could be more minimal. This way, we can have a cleaner appearance.
I am quite happy with this new layout, and I understand the concerns of many people very well. I had a similar experience with FlutterFlow, but after a while, I definitely realized that it was the right choice. So, I think making improvements is a very appropriate decision.
Brian, is that not what a group is for? Or am I missing something here? Groups collapse very nicely in FD…
A Group action creates an object, so another “layer” to access children.
For example, a Set value action named “first_name” inside a Group action named “user” would be accessed via user.first_name.
Cheers Keith thanks for the heads-up! And thank you to @George @Teodor @patrick for resolving those issues for those of us using a real OS! Eh Teodor… 
That’s great - thanks very much.
Could the comment section be collapsible? There is aleady a popover to display the text, so perhaps it’s meant to be collapsible (otherwise there wouldn’t be any point in having a popover).
Like real human beings!
“Brian, is that not what a group is for? Or am I missing something here? Groups collapse very nicely in FD…”
Group also acts on the output, grouping the output of all contained actions into a single JSON structure which is not typically what is needed.
see this post
+1 on keeping the old tree view in place.
Currently not on a Wappler project (or subscriber EDIT: subscribed just to test), but the new “graphical” designer I don’t like and from what I can read here, I don’t see a real benefit for existing users, BUT I understand it might attract new users from other platforms with probably simpler needs and actions of a very few steps.
Agreeing on every single point, Antony.
Marcel, thank you for being one of the few people on this planet to recognise my true brilliance! 
