Hello, basically, what I’m doing, is I’m repeating the new Dropzone in a bound div, a normal thing. But I’m struggling to get the instance’s context within the dropzone when using the component. This makes the whole point of a dropzone and binding the data useless?
I think I’ll use this thread as an observation about components, hopefully you won’t mind guys.
I think there is a VITAL need for the select of type “unit” or however the input for int values with css units is called.
Now to be able to bind width to something else than px, you need to either make it default, or come to the old way of “binding” it as a string. This implies making acrobatics like this,
Answering point by point :).
So here we are in the case when you want your dropzone content to have access to content from inside the component. In Vue it will be called slot variable. Its something we have in mind, but it is not available yet (for now you access only the context from the parent, meaning if your component is repeat, your dropzone content have access to this repeat context)
This is one is an easy one, as it already exist for custom code components, and our nocode component use exactly the same configuration internally. I will add you to our feature list
An other feature we have in mind is “Expose property”, letting you select some internal element of a component, but only allow a very few specific properties to be changed (padding or width for ex)
First of all, sorry for the hoard of suggestions. Any ETA on this?
It’s like a huge, if not the whole thing about components for me, to be able to bind this. Especially, as this would allow me to abstract whole logic into some cool stuff that you’d definitely like
Dang, I feel like I’m already hitting the limits, after like five hours of playing around
Hmm yes indeed, I did not think about this usecase. Variable are internal to each component and we reset only the global one. I will think about it :).
For the variable, if you are editing a component, you can see variable value on the left debug panel
Never be sorry for having feedbacks :).
We are already discussing about exposing at least the repeat context if the dropzone is repeat, and keep for later more advanced usecase when you could pass more data.
If we agree on this (everybody is sleeping right now) it can be up very quickly
For now, the major pain points I see, are the bound values (px, rems …) and the context. Other than that, even though it required some tinkering, everything seems to be amazing I managed to do already some things, that would save like, tons of time actually. And I’ve not even started…
The groups (for the fields) might end up being a nice to have too, as actually, I’m planning to make it like suuper customizable.
The only thing I think is gonna be a weakness of these overall for now, is the lack of the ability to either have, or set up more triggers such as pointer events, and keystrokes.
Edit: An idea might be, to actually make the various fields have a group such as variables, or collections, and maybe making those groups become the groups like in this picture? I’m not sure if it would make sense.
Indeed, that’s why I’m asking about it actually, I can imagine that adding a few lines of code to the ww-config is simple for people who know how to code, but abstracting it to no-code logic, that requires much more tinkering.
Yup, conditionals was my right another solution to this, but still, it becomes a huge list of fields, if you have like three features. For now I probably won’t be using groups tho, at least until the units are not there.
Among all of this, I think the biggest deal for me, is just the context, for the rest, it’s just cosmetics, that are not blocking the “logic - practical” part
It would also be great, to make the default/initial bindable imo.
For example, I wanted to make an internal randomized ID, so I can use it for IDs of elements.
Whats your expection on a dynamic default value? If no value is defined it alwayd fallback to the current value of it (then random ui does not work) or we evaluate it once when component is created? Or Mounted?
I was thinking about it for a while yesterday. Maybe an on mount workflow trigger would be great, this way we could set internal values/fetch some data etc.
For example I wanted to add a formula to generate a random id, in order to make the component unique and save it as the default value.
Oh sorry i thought you were talking about parameters.
For variable, the problem is the value will be different after each mount (including conditional rendering).
Is this correct?
I imagined it as a random value for each instance yes. This way I can for example use JS to focus input fields within that certain component etc.
I could make the users do this and pass the id as a prop, but it kinda takes away the power of abstracting this from regular no-coders. Also I don’t think this should be stored as a variable outside of the component, as it’s not essential for the scope outside of the component imo
A simple example is creating a counter as a reusable component where you want the parent to pass the initial count as a prop and then initialize a component variable that keeps track of the increments. The component variable needs to be bindable to the prop passed to the component otherwise the parent needs to trigger an action that changes the variable value to the prop. Basically it should be the equivalent of this
Lifecycle triggers would also be nice to have (mounted and beforeUnmount should be enough), paired with the reference to the DOM element would ease many integrations where a library needs to access the DOM.
