Using <component :is="..."> in nocode?

Developer corner
1

I’m wondering whether it’s possible or it will be possible to use dynamic component feature of vue?

I’d need to do something like wewebs workflow builder, but it should nest infinitely, the idea is, to have each Action, for example true/false, as a template, and then call them based on JSON.

Will this be possible in the reusable components update? This would be amazing.

Now it’s really a struggle, to do something repeatable sustainably. You can only “pre-nest” stuff but that’s a big tech debt.

What I’m hoping to be able to do is have a component element, where you can choose all your saved components from a dropdown maybe? And this name of it would also be bindable.

ff
ff337×796 21.5 KB

What it would generate would look something like this <component :is="trueFalseSplit">

2 Likes
2

It probably won’t come in the first release of the components, but a great idea and something to think about! Appreciate it

1 Like
3

:sad_broberto_face: ‎

4

You components will have different parameters and props, and you will not be able to edit it differently based on this dynamic condition. At this point you should make your own vue component rendering whatever you need, what is the plus value of using an editor if you throw repeatable dynamic json everywhere, better to code your logic

That said, in WeWeb with reusable component you will be able to do what you want, build a wrapper with this component name prop and use it to render the sub component by implementing a conditional rendering on every possible components you want to be able to render with this wrapper

1 Like
5

Yes, but if I want to render components within components within components, nested, then it won’t be possible right? Unless I pre-make like many of these nestings in the editor.

Let’s say I want to create someting like workflow builder in WeWeb. To do the actions nested under True/False branched item, I’d need to insert a component manually, but what if I want to have another if nested underneath the if I just inserted? I’d need to prepare it again for the user, instead of being able to “build” this dynamically, right?

6

You will be able to drop a reusable component into itself. (It still discussed if it will come in the first release but its the plan).

So you should be able to make a nested comment section for example.

7

Amazing, that’s what I hoped to hear. I have some projects in mind waiting for this.

as for this, I’m not sure if I understand you. Are you suggesting that if I’m using a lot of dynamic JSON, I should go classic code route instead?

8

I’m just guessing editing something as dynamic will feel like you’re fighting with WeWeb more than you’re using it

With custom code component you can also create WeWeb elements, its what we are doing for kanban for example, it generate stack elements, so its another approach you could make, if reusable component end up not doing the trick.

I’m not sure a general :is would make sense because every components have different props, events, settings

9

So far, it’s more bearable (in terms of speed), than having to code the stuff, that’s the whole point of using WeWeb I think.

One thing that I actually was thinking about (unrelated to the thread) is, checking for the partial update type, and giving possible edits based on that.
The thing is, that when I start from an object, and I store my state in it, for example, I store items: [] as a property, and then I store objects in items, which themselves have items: [...],

{
id: 420
items : [
         {
          id: 123,
          items: [
             {
                id: 321, 
                items: [...]
             },
          ...
           ]
        }
   ]
}

I’m losing all the power of nocode action, Change Variable Value (as it works only on the type of the " top level" parent’s type) and I find myself using a lot of JS. A cool thing would be, that WeWeb would under the hood, check what typeof is my path refering to, so if it’s an array, it would give me the amazing options, like Insert at index, Insert at the end etc.

I know it’s not a usecase, but I think sacrificing WeWeb’s super fast time saving frontend builder just because my logic has some more complexity, I dunno. I think this might be the next thing to focus for you guys on. To make it sustainable also when things get more complex, than simple variables :slight_smile:

10

I understand your needs, and it would be great for your usercase yes. But a property is not typed. So what if you can both have null and an array/object inside the property ? The UI displayed will depends of what value is currently inside your variable while you’re editing it.

In WeWeb we are working with a static structure and typed variable because it help us to provide a maximum value around it.

So your question is not that unrelated with the thread, it still about working with dynamic structure inside WeWeb.

The issue with dynamic structure is it depends of the runtime execution where everything can happen and your app can be in a whole different state from the one it was when you edited it, because you’re editing things in a static state of your app.
Only you know about the different possibilities you have in mind with your dynamic structure. By putting dynamic JSON and getting ride of using the editor to define your structure you also do WeWeb “blind” about your project.

This is why making a reusable component yourself with with a :is prop and building your rendering logic inside the reusable component (by putting every possible component inside with a rendering condition on every component) feel more the right way to works with WeWeb atm, it ensure you made WeWeb know about what can happen.

This is why I tend to suggest custom code when you’re working with dynamic data structure, because you can handle the dynamic part yourself in the code.

It’s the same for the supabase suggestion you made about binding the table. Once you bind the table how WeWeb know the fields you should be able to configure as everything become possible ?
If we are doing a supabase action where you bind the table and the payload, the value provided by the UI may be not worth enough versus using a custom js action where you call the sdk yourself for exemple.

What I mean is, the more blind WeWeb is about what you want to do and the less it will be able to provide a relevant UI to manage your stuff.

And it’s not a WeWeb thing, To me it’s a general conceptual problem, a huge UI/UX challenge and it will always require balance to put the cursor in the right place, to not make the UI too much complex/clunky but still be able to manage complex stuff. For now our response is, when things become too complex, you can still fallback to code.

As things cannot be represented in a UI the same way they are represented in code, you will always have to think different once you reach a certain point in term of complexity (to achieve the same thing with an UI and with code). We are still trying to push the limit as far as we can, but we have to carefully evaluate the tradeoff for every new step we make :thinking:

I can give you a simple example, the components variables can exist or not depending of the state of your app, if the component is not rendered, the variable doesn’t exist, so if your component is inside a modal and the modal is not opened, the variable does not exist, a lot of people find this situation confusing. They will try to bind the variable in a workflow, and the workflow will allow it, even if he will be executed only in a situation where the variable doesn’t exist. Because we can’t know what the person will happen in his app.

To me, it’s not a WeWeb limit, it’s the limit of using an UI to build web app as a concept itself, not a purely technical limitation. But yeah, trying to figure out a way to continue to push the limit and yet keep it manageable by most of people is our daily life, the main goal of this company! haha

Hope it make sense!

Note: I just wanted to share my thoughts with you as it’s a subject I also have in mind frequently, still trying to figure out what we can do about it :slight_smile:

3 Likes