Questions around client side logic, aka "Inline Flows", "Page Flows" and "App Flows"

I try to get my head around the client side of scripting, aka “Flows” with Wappler and want to confirm if I understand the concept correctly. I would appreciate if you, as experienced users, can chime in and either confirm or correct me where I went wrong.

For me, it looks like we have four ways of scripting “complex” logic in Wappler:

  1. Actions
  2. Inline Flows
  3. Page Flows
  4. App Flows

Actions and Inline Flows are available on dynamic events on specific page elements.
(On “static events”, I can’t do anything except entering something, no Actions Editor or Inline Flow Buttons available?)

  1. Actions
  • Not reusable as they are attached to specific event of a specific element
  • Call methods (“Actions”) on components that are available on the current page
  • No input parameters
  • No return values
  1. Inline Flows
  • Not reusable as they are attached to a specific event of a specific element
  • Accept input parameters, can’t figure out why (bound to a element?) and how to use them
  • Call methods (“Actions”) of globally available components
  • Supports a “run” step which utilises the Actions Editor (as in “1. Actions”)
  • Has a “Enable Output” toggle on steps, but how to access this result?
  • Supports conditions

Page- and App Flows are globally, either for the page or the app

  1. Page Flows
  • Unlike Actions and Inline Flows, Page Flows can be called from different events of different elements across the current page
  • Return values (“output”) are avaible via data binding
  • Auto Run works perfectly, but how to call Page Flow from a dynamic event, as a button click?
  • Again, can’t figure out how to pass params, are this query params?
  1. App Flows
  • Separate Flow Editor in Workflow Tab
  • Globally available to all pages
  • No access to components like Capacitor or SQLite (why? Espcially SQLite would make sense here?)

Questions in general:

  • Where to find documentation about the steps / actions, like the Data Sources (Assign var, Set Global, Set Session/ Remove Session, No read Session? / Set or Remove Storage, no read?), what are Data Sets? Columns? (to name a few…)
  • How to run subsequent flows, e.g. branching after conditions? Run Flow step seems to support a Flow attribute, but what to enter here? Do I have to import all flows, including subsequent flows into the page and name them identically as in the Workflow tab?

Observations / bugs found while writing this:

  • None of the steps that require external JS work, Toast, Bootbox, Capacitor… (JS not found, as it’s not added to the page)- Inline Flow editor randomly didn’t save changes OR emptied the editor (while the script was still visible in code view)
  • Added Capacitor to the flow (Wappler had to install the package first), the flow editor closed on save and was empty afterwards
  • On the Inline Flow editor, Framework7 have been availble even if the framework wasn’t available / added to the page/project (Bug?)
  • App Flows: Params not working (emptied after re-opening the editor, bug)
  • App Flows: Data Binding for return variables not availble in data picker, only data, had to add name of the variable manually
3 Likes

Generally your other descriptions are all correct.

My thoughts:

Correct, these can run static javascript

Same as for everything else…some here, some there, etc. Basically the forum. I recall reference material being developed at one point to go along with the examples shown in the forum, not sure of the status

I end up using a Run action to branch to other flows instead of the flow action itself.

This is what keeps me from using app flows currently. I think the idea was the link to a page, and use its data bindings, but that never works for me.

I’ve been seeing this across other areas of the editor as well. I’ve been lax in reporting them as bugs as it is hard to capture a log file.

One thing I’ll add about inline flows vs page flow, is that the resulting code of a page flow if MUCH easier to edit when having to get around bugs or manually change things.

Also a note that running a list of actions is not synchronous even though they appear to have order, while inside a flow, they are (except for inside a Run action where you can again have a list of actions.)

I don’t think the UI shows this, but I might be mistaken. But you can view its structure in the dev console with dmx.app.data and manually reference if needed.

You should see the option to run a page flow within the bindings, I use that a lot from all sorts of events.

If you setup params in the page flow, when you select to run the page flow, you will see the params (perhaps you were using the flow action which I never use.) Inside the page flow they can be selected, or manually found at $param.param_name

2 Likes

Feels like Wappler is great for server side development, or purely static bootstrap sites, but anything modern / complex on the frontend (SPAs and mobile) requires a lot of manual effort which makes Wappler more of a source of frustration then improving productivity, especially with so many bugs, random crashes and unfinished features for a premium price tag of 600€-1300€ / p.a. + VAT :frowning_face:

1 Like

Indeed the flows are a natural evolution of the actions on your page and allow you do to much more complex logic. Action trigger just a single action and have no return value indeed, while flows can contain more complex logic, has a bit the same power as server connect actions on the server but flows are all on the client side.

Inline flows are indeed just inline per element, while page are on the page for reuse on that page and app flows are more global indeed to be used on multiple pages.

Inline and Page Flows indeed have access to the page components and can run their actions, while App Flows because they are global or just global actions on their own that have no knowledge about the page that runs them.

App Flows are global and some components are dependent on the frameworks used on the main page or capacitor/cordova. Like SQLite plugin requires capacitor. But indeed as it is selected as runtime, we should be able to detect it and allow the SQLite plugin usage in app Flows. So will see if we can improve this.

Well all actions in a flow are sequential. They are action promise based. So always run one after another and only after the previous was successful. If you do run an external app flow, then it is waited till it completes to go to the next action steps.

Keep reporting any bugs as separate topics, but do make that you list the exact steps to reproduce, so we can easily track them.

3 posts were split to a new topic: Capacitor framework wrongly included on web projects