-
-
Notifications
You must be signed in to change notification settings - Fork 629
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Data attributes for layers #2827
Conversation
Hello, @DarKsandr! Thank you for the ping. Could you share some details about the task? I feel like this change might not significantly simplify the code for reuse. If we're talking about applying it only on one screen, perhaps we could achieve the same effect by adding a method to this screen's class: public function frontEndController() : string {
return 'hello';
} This approach would allow us to apply the changes to the entire form or even page. What do you think about this idea? |
@tabuna This is a good idea, but as an addition to mine. What if I want to assign different controllers to different layers? Let's say there is a filter and a table with data on the page: there will be one controller for the filter, and another for the table. |
Usually, I create my own layers for display, which is not difficult at all. Also, we already have a Layout::stimulus('hello', [SimpleRow::class], ['url' => 'keyForQuery', 'model' => 'keyForQuery']) And the result: <div data-controller="hello"
data-hello-url-value="http://example.com"
data-hello-model-value='{json}'
>
<!-- ... -->
</div> We could also make the third argument optional, so that no values are passed to the controller, and make the second argument act like a modal window, allowing either an array or a single value to be passed. Layout::stimulus('hello', SimpleRow::class) Furthermore, we could use the same names for both front-end and back-end values: Layout::stimulus('hello', SimpleRow::class, ['url', 'model']) @DarKsandr, sorry for the delay in responding, as I'm currently observing national holidays. What do you think about it? |
@tabuna I assumed that the wrapper requires a blade template. I wanted to give attributes to layers, just as this has already been done for elements (set method). It’s also not very clear why there is an additional layer just for the data attribute? and yes, I also celebrate May 9th (С Днём Победы) |
@tabuna Did you decide anything about the implementation? |
Hi @DarKsandr ! If we start explicitly defining attributes for each layout, we may find it difficult to stop later on. For example, currently, there's support for data attributes, and then we might add our own One of the main reasons is also that this approach does not promote code reuse. It's unlikely that you'll be able to reuse what's written this way due to the complexity of documentation and support. Let me clarify this point. Currently, there aren't many extensions (Layout/Fields) in the community that we could use. If you create a JavaScript controller for fields (similar to UTM), it may be possible to not only reuse it, but also share it with others. However, if it's divided into more files, the likelihood of it being documented, supported, and looking good decreases (in my opinion). I would prefer not to increase what's called the "reason for changes". I understand that you're referring to the experience with If you're interested, I can provide a simple example (which doesn't affect PR and only leads to the fact that <div class="">
<input name="start">
<input name="end">
</div> Which of these three elements should data attributes be applied to? There's no good answer to this question, as we can add attributes to the If you have a situation where you can't create a component and instead are trying to configure something, I'll try to help, and together we can find a good solution. If you're unable to disclose any information publicly, we can discuss it via private messages on Telegram. |
Done to assign a data controller for the layer. Subsequently use the Stimulus.
Example: