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?
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)
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
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
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 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.