I have a custom component and would like to apply the exact same styles as the <Typography> component gets when setting the noWrap prop. The following does work:
<span className="MuiTypography-noWrap">
But there's of course no actual type-checking or "link" to anything here, which means if the name ever changes or is removed in a future version, I won't get any type/build error from it.
Is there a "Material UI way" to reuse/copy these classes? E.g. is there somewhere I can import/access these names from?
I assume you have a reason, but given your example of a span element, I can't help but wonder why you're not just using the MUI component.
I've never done this before, but I was curious and the styles are indeed exported. Not sure if this is a good idea or if there is another way...
import { styles } from '#material-ui/core/Typography/Typography';
const noWrapStyles = styles(theme).noWrap;
Related
Let's say I want to check this component render its child with the right initial props
const { container } = render(<Header/>)
Where is
<div> <SomeChild custom-prop=innerHeaderVariableLikeInitialState /> </div>
Before I can try to check anything when I run my test I get the prop 'custom-prop' is marked as required but it's value is undefined (I use prop types)
So it means the react-testing-library doesn't initialize its child componenent ?
How to manage this ? I feel I'm not taking this with the right angle
Thanks
What you're looking for is probably container.firstChild.
However, testing for the presence of certain props goes against the "don't test implementation details" approach of react-testing-library. Really, there's no way to do that with the rendered output, as it's all DOM elements, not React components. Instead, consider what user-facing elements you could look for, like text, accessibility labels, etc. How can you verify the user is seeing what you expect them to see?
I've tried all the HTL context parameters (even 'unsafe'). When I inspect the input, I can see the value intact, but you can't see the value pre-populated in the field. I tried different types of values, different contexts, and different types of input fields. [AEM 6.2]
<input type="email" name="senderEmail" value="${userProfile.email # context='text'}"/>
If the value is rendered in page source and also visible in browser inspector, could it be that it's hidden by some weird CSS? Something like color:transparent
There are many possible causes. I'll pitch in one, to help get you thinking. Is userProfile available via the use api?
I've made this mistake before:
<div data-sly-use.bean="com.beans.Bean">
${bean.value}
</div>
// ... other code
${bean.value}
The "Bean" isn't available later, outside it's host element.
If I understand your question correctly this isn't actually about HTL, but rather about the HTML input element itself. You have an input element with a value attribute set, yet that value is not displaying in the box. If that's correct, then I'd recommend doing some investigation around HTML input value not displaying when set, rather than sightly context issues.
Some possible answer would include css styles hiding the input text or javascript clearing out the values after page load. There are certainly more potential causes, but we'd need to know more about your page to provide a better answer.
To do some of your investigation you can try loading a component with only that input in it and see if that works, that would eliminate any css or js executing elsewhere on the page.
Hi I have several js/mootools code in a coffee file that I want to combine together as in
$$("#head").setStyle('border-right-color','#e64626');
$$("#head").setStyle('background','#e64626');
$$("#console").setStyle('border-right-color','#e64626');
$$("#console").setStyle('background','#e64626');
Is it possible to combine this into one line?
Although what #sergio gave you is the correct answer and what you wanted, it's probably the wrong thing to do (though his answer is not at fault, its the question that is off).
Setting element inline styles in JavaScript for effects is just not a very good practice. It has its uses in animation/fx but this does not seem to be the case. The reason is that it breaks cascading due to the high specificity and makes it much more difficult to revert, control or change afterwards. It also makes it harder to skin and restyle your app as there's a clear lack of separation of concerns, style in code is rigid.
You need to solve this via CSS
scenario 1: static, non mutable - not very good due to use of ID rather than classes but:
#head, #console {
border-right-color: #e6426;
background-color: #e6426;
}
scenario 2: dynamic, need to differentiate elements on some event such as click, focus, mouseover - though you can solve most of these with pseudos like :focus or :hover, then abstract this into a class:
css:
.highlight-red {
border-right-color: #e6426;
background-color: #e6426;
}
javascript:
var els = $$('#head,#console');
// on whatever event...
els.addClass('highlight-red');
// ... later
els.removeClass('highlight-red');
you will thank yourself later or your successor will or your client, whatever. this has the added benefit that next time you need to change styling or add more rules to differentiate, you have one place to go to. you can even add transitions / animation effects for evergreen browsers.
You can use setStyles() and pass it a object. You can also use , in the string you pass to $$ to select multiple elements. So it would result into:
$$("#head, #console").setStyles({
'border-right-color': '#e64626',
'background': '#e64626'
});
jsFiddle: http://jsfiddle.net/sevvtsx0/
I am new to Play Framework and still trying to wrap my head around some things with the new Scala template engine.
Let's say I have the following package structure:
app/
app/controllers/Items.scala
app/models/Item.scala
app/views/layouts/page.scala.html
app/views/item/show.scala.html
app/views/item/details.scala.html //partial
And this is my item/show template:
#(item: Item, form: Form[Item])(implicit flash: Flash)
#layout.page() {
#*want to include details partial, wont work due to item param*#
#item.details(item)
}
Since including another template (e.g. including item/details above) is the exact same syntax as accessing a template parameter (e.g. item above), obviously this existing naming convention won't work without something changing.
I know I can rename my "app.views.item" package to "app.views.items", and rely on singular/plural forms to differentiate the view from the param name, but this does not seem like a very straightforward solution. Also what if I really want the parameter name to be the same as the view package?
One idea I have is to prepend all my views with an extra top level package:
app/views/views/item/details.scala.html
So the include syntax would be #views.item.details(), but again this is obviously a hack.
What is a good way to avoid this issue? How can I better organize my code to avoid such naming collisions?
Most other template engines use operations like "include" or "render" to specify a partial include. I don't mean to offend anyone here, but is the Play Scala template engine syntax so terse that it actually dictates the organization of code?
3 solutions:
First
Typpicaly for partial templates you should use tags as described in the docs, where app/views/tags folder is a base:
file: app/views/tags/product.scala.html
in the templates (no initial import required in the parent view full syntax will allow you to avoid name-clash: #tags.packageName.tagName()):
<div id="container">
#tags.product(item)
</div>
Of course in your case you can also use packages in the base folder
file: app/views/tags/item/product.scala.html
<div id="container">
#tags.item.product(item)
</div>
I'm pretty sure that'll solve your problem.
Second
To avoid clash without changing package's name you can just rename the item in your view, also I recommend do not use a form name for the Form[T] as it can conflict with helpers:
#(existingItem: Item, existingItemForm: Form[Item])(implicit flash: Flash)
#layout.page() {
#item.details(existingItem)
}
Third
If you'll fill your Form[Item] before passing to the view with given Item object, you don't need to pass both, as most probably you can get data from the form:
#(itemForm: Form[Item])(implicit flash: Flash)
#layout.page() {
<div>Name of item is: #itemForm("name").value (this is a replacemnet for ##existingItem.name </div>
#item.details(itemForm)
}
Of course in you product.scala.html you'll need to change the #(item: Item) param to #(itemForm: Form[Item])
I have some GWT code here. I am trying to change the background color of a widget:
this.getElement().setAttribute("backgroundColor", backgroundColor);
this.getElement().setPropertyString("backgroundColor", backgroundColor);
this.getElement().getStyle().setProperty("backgroundColor", backgroundColor);
Usually in code I can tell by the name of the function what the code does... but in this case all three lines of code looks the same and "read the same"! (Reading the javadoc did not help either.I went to the javadoc because that usually helps me understand what code does. The javadoc did not help.)
My question to you is: Please explain what is the differences between these three lines of code (for instance why do you need to call getStyle())? Why does the last line work?
this.getElement().getStyle().setProperty("backgroundColor", backgroundColor);
is the only line that access the actual style information, properties and attributes manipulate the element directly and don't have anything to do with the Style that is associated with an element.
And just as an addition, you should really be using a style sheet and changing the style instead of setting inline this way.
It is the difference between
<tag backgroundColor="#f0f0f0">
and
<tag style="background-color:#f0f0f0">
This is somewhat of an educated guess...
Line 1 you are accessing the element's attributes not the styling attributes.
Line 2 would access properties on the element not the styling.
Line 3 actually gets the styling properties and then changes them accordingly.