I am trying to create some composition but I am not getting anything I'd expect. In almost every instance I've tried a similar setup I get something different which is wrong so this GistRun is representative only as far as it illustrates that at least "something" is wrong.
I've searched high and low for more information on the specific functionality and syntax of compose but I can't seem to solve the issues.
In the before mentioned GistRun you can see that the Container element is not rendered correctly, the h1 is not rendered and that #containerless is being ignored.
In similar scenarios I've had containerless ignored on the compose element resulting in the rendering being ignored and I've had the entire thing not working with named slots.
I have a feeling that I'm doing something wrong and I can't quite figure out what it is. If someone knows what I'm doing wrong or can point me to a solution I would be much obliged.
Part of the reason things aren't working as you expect is that your gist is based off of a very old version of the framework. I've updated your gist to the latest version of Jeremy Danyow's Aurelia bundle here: https://gist.run/?id=1b304bb0c6dc98b23f4a3994acc280e4 The old version of the framework you were using in your gist still used the content element for content projection.
There are a couple of reasons your gist wouldn't run (aside from what I mentioned above). First, the compose element (and any custom elements you create) are not self-closing. This is per the Custom Element spec. So <compose view="test.html" /> wont' work. Second, there is an existing issue regarding containerless elements being used with content projection. After talking with the team, this issue is unlikely to be resolved as containerless custom elements aren't really supported by the Shadow DOM v1 spec. If you remove the containerless attribute from the compose element, your demo works. Finally, you forgot to add <require from="container"></require> at the top of your app.html file. Thus Aurelia was unaware that <ck-container> is an Aurelia custom element. Unless you have globally registered a custom element (or any other view resource), you MUST require it in to any view where you wish to use it.
Now, let's discuss the use of containerless. The containerless decorator and attribute shouldn't be used simply to "clean up" your HTML. They should only be used when absolutely necessary to achieve your goals. "Making my HTML pretty" is never absolutely necessary. When you use containerless you are creating a custom element that likely cannot ever be used as a standard custom element. Again, the Aurelia team discourages you from using containerless elements unless necessary.
An example of a valid reason to use containerless is expained in our documentation here: http://aurelia.io/hub.html#/doc/article/aurelia/framework/latest/cheat-sheet/4
Related
Example of the HTML of a dropdown element:
<div aria-owns="ember-basic-dropdown-content-ember1234" tabindex="0" data-ebd-id="ember1234-trigger" role="button" id="ember1235" class="ember-power-select-trigger ember-basic-dropdown-trigger ember-view"> <!---->
<span class="ember-power-select-status-icon"></span>
</div>
The xpath and CSS selector also contain the same ember id.
xpath : //*[#id="ember1235"]
css selector : #ember1235
The ember id would change from id="ember1235" to say, id="ember1265" when there is a change in the UI.
I am using id to locate the element. But every time it changes I need to modify the code. Is there any other attribute I could use for Ember JS UI elements?
There is quite a lot to discuss in your question but hopefully we will have a good answer for you #PriyaK
The first thing to mention is that Ember IDs may not be the best method to select an element in the DOM. As you have already mentioned, they can change from time to time and also it doesn't really give you a great semantic thing to select in your selenium test so it might seem a bit out of context when looking back.
One thing that you could try is to either pass a class to the ember-power-select component (the one that provides the HTML that you used in your example) and use that to select the element, something like:
<PowerSelect
#class="my-fancy-class"
as |name|
>
{{name}}
</PowerSelect>
Then you should be able to select the selected value by using the CSS selector .my-fancy-class span (because the component outputs the selected value in a span)
We just tried this in an example app but it didn't actually work 🤔 Never fear, you can also do something like this and it should work with the same selector as before:
<div class="my-fancy-class">
<PowerSelect as |name|>
{{name}}
</PowerSelect>
</div>
This is fine, but there are also a few issues using classes for selectors in tests. One example of a problem that might crop up is that your tests might all suddenly stop working if you did a style refactor and changed or removed some of the classes on your elements. One technique that has become popular in the Ember community is to use data-test- attributes on your DOM nodes like this:
<div data-test-my-fancy-select>
<PowerSelect
#class="my-fancy-class"
as |name|
>
{{name}}
</PowerSelect>
</div>
which can then be accessed by the following selector: [data-test-my-fancy-select] span. This is great for a few reasons! Firstly it separates the implementation of your application and tests from your styling and avoids the issue I described above. The second benefit of this method is that using what #Gokul suggested in the comments, the ember-test-selectors package, you can make use of these data-test- selectors in your development and test environments but they will be automatically removed from your production build. This is great to keep your DOM clean in production but also, depending on the size of your application, could save you a reasonable amount of size in your templates on aggregate.
I know you say that you are using selenium for your testing but it's also worth mentioning that if you're using the built-in Ember testing system you will be able to make use of some testing helpers that addons may provide you. ember-power-select is one of those addons that provides specific testing helpers and you can read more about it in their documentation: https://ember-power-select.com/docs/test-helpers
I hope this answers any questions you had!
This question was answered as part of "May I Ask a Question" Season 3 Episode 1. If you would like to see us discuss this answer in full you can check out the video here: https://www.youtube.com/watch?v=1DAJXUucnQU
I'm developing a Vue app using UI Kit which implies using various custom attributes like uk-grid, uk-icon, uk-navbar etc (in Vue single file components' templates). For each one, IntelliJ gives me a warning like
Warning:(7, 52) Attribute uk-icon is not allowed here
How can I tell IntelliJ not to do this? Googling the warning haven't brought any sane results which makes me think there's no ready-to-use package for this (for this particular UI Kit), so the question is: how to make Idea not to warn about a custom list of attributes? But I'll be glad to be wrong and if there is a better solution, please let me know.
Update: like lena has suggested, pressing alt+enter suggests helpful options, including adding attribute to the list of custom attributes. However, wildcard suggestion didn't work for me: the below screenshot illustrates settings that make v-localize attrbute be recognized, but uk--prefixed attribute are still highlighted with warning:
You can add uk-* attributes to Custom HTML tag attributes list in HTML | Unknown HTML tag attribute inspection; the easiest way to do this is using Add to custom HTML attributes quickfix available on Alt+Enter:
Note that IDEA recognizes Vuikit components and directives out of the box - did you consider using it instead of pure UIKit?
We have implemented checkbox in popover. There we are using checked.bind , but in the view model its not reflecting its value on change of the checkboxes.
Sample Gist Run Provided below:
Gist Run
Thanks in Advance
Programmatically injected HTML needs to be compiled manually
The integration with bootstrap I provided to you earlier cannot do this. The bootstrap plugin assigns the innerHTML property of the popover and it does this outside of aurelia's rendering pipeline. The HTML is therefore not compiled by aurelia, which is why bindings (and other aurelia behaviors) will not work.
The templating framework takes care of this for you automatically as long as you are following conventions (such as custom elements). In any other case you'll need to manually work with the ViewCompiler.
In case you're interested, you can see an example with programmatically generated HTML in this gist. Also see this question if you want to know more about it. I do not recommend it in this scenario however.
Use aurelia-dialog
A tooltip (or popover) is just that: a tip on how to use the tool. It should not need more than some plain markup, text and styling (of course this is subjective to some degree, and some people may disagree)
For collecting user input in-between pages or screens, I'd argue a modal dialog is a better fit because of its property to "pop out" more and to de-emphasize the rest of the screen until the user either proceeds or cancels.
More importantly, by using aurelia-dialog your bindings and behaviors will simply work because, well, it's an aurelia plugin :-)
Protractor 1.7.0 has introduced a new feature: a new locator by.deepCss which helps to find elements within a shadow DOM.
Which use cases does it cover? When would you want to reach elements in the shadow DOM?
The reason I ask the question is that I'm missing on the motivational part of the matter - I thought about protractor mainly as a high-level framework that helps to mimic real user interactions. Accessing shadow trees sounds like a very deep down technical thing and why would you want to do it is confusing me.
To answer your question, here's a related question: "what information does shadow dom provide that looking at raw html does not?"
The following snippet creates a shadom dom (view via chrome or firefox):
<input type="date">
If you click on the arrow, a pop up opens with all the dates, and you can select it.
Now imagine you are building a hotel reservation app and you made a custom shadow dom date picker, where it would black out (and not allow user to select) dates when rooms are unavailable.
Looking at the raw html, you see <input type="date">, and the value/dates that a user selected. However, how would you test that the black out UI is working as intended? For that you would need to examine the shadow dom, where the pop up resides.
The reason I ask the question is that I'm missing on the motivational part of the matter - I thought about protractor mainly as a high-level framework that helps to mimic real user interactions. Accessing shadow trees sounds like a very deep down technical thing and why would you want to do it is confusing me.
Doesn't seem so in this website that shows an introduction to shadow DOM. It says that:
Shadow DOM separates content from presentation thereby eliminating naming conflicts and improving code expression.
Shadow DOM mainly helps with separating content to avoid naming conflicts and improving your code expression, making it neater and better (I assume). I am sorry to say that I don't actually use Selenium, so here is a website with plenty more information: http://webcomponents.org/polyfills/shadow-dom/
I hope this helps you!
I was experimenting with Dojo and Dijit in the past days and I find it quite interesting. I was however trying to find a reference or an API doc that helps me understand all the properties I can assign to widgets and containers.
For example a Tab with a Save Icon will be like this:
<div data-dojo-type="dijit.layout.ContentPane" title="Group Two" data-dojo-props="iconClass: 'dijitEditorIcon dijitEditorIconSave'">
Now, where can I find what to put in the "data-dojo-props" property? Where can I find for example all the list of icons?
My main question would be for example on how to create a vertical menubar, but beyond odd examples scattered here and there, the api reference is not much helpful...
Any help? Am I missing something here?
For this kind of situation, the trick is learning how to convert between the programmatic Javascript style and the declarative HTML style (and sometimes also between the old declarative style, without data).
For the new declarative style, basically the only "real" argument now is data-dojo-props and it consists of an object that will be passed to the widget constructor.
//programatic style
new dijit.myWidget({foo:'a', bar:'b'});
//declarative style
<div data-dojo-type="dijit.myWidget" data-dojo-props="foo:'a', bar:'b'"></div>
You can find what properties an widget accepts by checking the corresponding widget documentation and looking for either declarative or programmatic examples (now that we know how to convert between them). If that is not enough, you can also check the source code - it is usually very well commented and is where api.dojotoolkit.org gets its data from anyway.