![]() But of course it takes longer, and (the initial versions at least) are unlikely to be as powerful and robust as what the discourse team or the ember team have built. When the coding is done, it’s nice to have code that I fully understand and can customize. That’s where I’ve been tending to end up. So this is probably the best option, I think, if it is possible. In that case, I might miss out cool new features that discourse might add to its drop-downs, but I would be able to stay on top of how my drop-down works more easily. Option 2: I could insert something from ember that is robust but that is also made to be customized, where I can see fairly clearly how the code actually works. This is the task that I described earlier as being tricky.Īnd it could be difficult to maintain–because if the discourse team changes something in how the category-chooser select-kit code works, then that could change my new customized drop-down, but in ways that could be surprising (bc I had customized it so it works slightly differently than the actual category-choose dropdown). Option 1: I could try to take the select-kit code I see in, say, category-chooser, and insert it in a new spot (that’s not about categories), and then try to customize it to be about what I want the dropdown to be about, instead of categories. For example, if I wanted to add a custom field to topics, I’d always customize on top of discourse’s pre-built methods and code.īut If its a targeted piece of functionality–like a drop-down for a new purpose–I’d already be in the case where, if I use the discourse methods, I’d be adapting them to things they weren’t targeted towards. In this example above Im using the options verticalPosition and horizontalPosition to override the default behaviour. That distinction is probably important–I’m talking here about trying to do new things in a plugin that are not done in the discourse code-base, and the question is whether to start with discourse methods or a separate add-on.Ī lot of times you really don’t have a choice. ![]() Recently I had an interesting case that I needed to have all options loaded client-side and the number of options was not small (several thousands). It is working with normal action-handling by setting a value for 'destination' in js and assigning 'destination' to 'selected'. If possible I would consider styling the search box with CSS as this would be way less complex and does not add that maintenance burden. This is my thinking:Įxample here is wanting to add a brand new drop-down in a plugin. Ember-Power-Select is a very powerful EmberJS addon for creating drop-down selects. Ember Power Select provides quite a lot information to that component. In terms of using the discourse “abstracted stuff” v ember add-ons: I could be wrong, but I think that using ember add-ons for specific tasks in plugins might be easier to maintain, in the cases where you are trying to do something different than what Discourse is doing already. But I’m fairly certain that you’ll be much better off if you manage to deal with the “heavily abstracted” stuff and play by those rules ember-simple-auth is a runtime addon for implementing authentication and authorization. ember - basic - dropdown - content - below. ember-power-select is a runtime addon providing a powerful, and extensible
0 Comments
Leave a Reply. |