I picked up a react project that uses className={css.someStyle} format to link css to components. The problem is that I installed a package and I cannot get any css from it because my app only takes className how I showed you above, and the package, i saw, uses className="some_style" format.
How can I make my app accept className="some_style" format ?
If the information you are giving is correct the app is using CSS modules. That is why you see className={something.something}. className by default uses two different ways to take a class.
className="string" - the string can be any format like 'string-string', 'string__string' or something else. Do know that if you have a string separated by space it becomes two different classes.
className={variable} - with this syntax you can pass variable, css modules and expressions between the curly brackets.
To answer your question: Nothing should be preventing you from using the synthax className="some_style". Just be sure you are not surrounding the string with {} like className={"some_style"} because this will not work.
Related
I am using Handlebars templates. If I want to insert a variable in an hbs file, I add it as {{var_name}}.
The issue is, I have a large object with its keys taking formats similar to:
{
"stats.name":"John",
"stats.performance.day":123,
"stats.performance.month":4567,
"company":"My LLC"
}
If I try to add these to the Handlebars file as {{company}}, {{stats.name}}, {{stats.performance.day}}, {{stats.performance.month}} then only the {{company}} will be displayed. All other values come out blank, I assume because "." is a special character in Handlebars.
My question is, is there a way to override this, or do I actually need to iterate through this object and change every "." to a "_" or something before passing it to Handlebars to make it work?
I would recommend renaming your properties. Dot Notation is one of the two ways to access object properties in JavaScript. Typical code would look like: obj.prop. If your object's keys are not valid identifiers, then you must use Bracket Notation: obj['my-prop']. Since a dot is a property accessor, it is very unusual to see one in a property name. If I were to come across code written as obj['stats.performance.date'], I would assume it was a mistake and that obj.stats.performance.date was intended.
With that said, Handlebars does support referencing properties that are not valid identifiers. This is called "segment-literal-notation", and it is as simple as wrapping square brackets around your identifier:
{{[stats.performance.day]}}
The documentation also states that:
JavaScript-style strings, " and ', may also be used vs. [ pairs.
So the following alternatives are valid:
{{"stats.performance.day"}}
{{'stats.performance.day'}}
I'm aware that there are some languages that writes the order of some characters differently than the common latin languages. E.g.: a percentage number in English would be like "100%", while in Persian it would be "/100" (the symbol comes before the number).
Question: how to consider that in the Qt internationalization system in an intelligent way?
I first thought about this code:
myLabel->setText(tr("%1%2").arg(value).arg(tr("%")));
So what would happen is that, in the Qt Linguist, the translator would change the order of the replacement fields:
%1%2 -> in Persian translation -> %2%1
I checked that in my code and I found out that while in the normal (English) translation everything was fine, when I changed to the file containing the performed translation, a bug would occur: the number to be shown was never complete having one less number that what I had written. So e.g. if I chose "99%", it would show "%9", and if I set only "9%", I would have just "%".
The problem disappeared when I put a space between %1 and %2 both in the source code as well as in the translation (%2 %1). Since ISO xxxxx says that the % should be placed with a space between it and the correspondent number, no problem for this specific situation. But what If I wanted to have both symbols without a space between each other? How should it be done?
I confirm that the problem you described exists. However I would solve this problem in the following way:
QString sPer = QString("%%1").arg(value); // %99
QString sEng = QString("%1%").arg(value); // 99%
So that
%1% -> in Persian translation -> %%1
Put the percentage inside the string to translate, something like
myLabel->setText(tr("%%1").arg(value))
even better, I think I would add a disambiguation string (Qt "old style" comment)
myLabel->setText(tr("%%1", "Show the number with a percentage").arg(value))
or maybe a new style translation comment like this
//: Show the number with a percentage
myLabel->setText(tr("%%1").arg(value))
Translator comments have issues of their own, you might be better off using a Qt disambiguation string like the preceding example.
Putting a disambiguation string (or a translator comment) will let your translator know what they are translating...
Let the translators decide where they want to put the percentage, don't try to handle it in the code as somebody else suggested, it is not scalable, you can't start handling this in the code like that, what if you need to use another character or formatting for another language?
It might even be possible that Qt might have calls to handle number formatting but I can't seem to find them at the moment and I am not fully sure how we handle them in the Qt application I work on...
If putting a % alone doesn't work, try to precede it with \, it might be necessary to escape it, I am not sure...
I'm using Grunt and Assemble to create precompiled templates on my site but I need to dynamically create some sections based on information stored in client-side storage. Is there a way to exempt sections of a template from precompilation?
We can't do custom delimiters (a shortcoming of Handlebars), but there are a couple of solutions that might work for you. Neither is necessarily idiomatic, so you be the judge of how suitable these are for the project you're working on.
string replacement
You could use some custom (temporary) delimiters for the templates in the content that shouldn't be compiled, then create a block helper that will convert those delimiters back to valid handlebars expressions during compile time (I tested this for this answer and it works):
For example:
Handlebars.registerHelper("raw", function(options) {
return options.fn(this).replace(/\[\[/g, '{{').replace(/\]\]/g, '}}');
});
Then use it like this:
{{#raw}}
{{> foo }}
{{/raw}}
Inside foo.hbs, you might have something like this:
<title>[[title]]</title>
and it will render to:
<title>{{title}}</title>
This solution is hacky for sure, and you might have problems if you happen have any code examples embedded in the included content and one of the examples happens to have that syntax (like [0,1,[foo, bar]].
escaping
This solution is most likely the better way to go. Handlebars will not evaluate any templates that are preceded by \. So you can do this:
<title>\{{title}}</title>
and it will render to:
<title>{{title}}</title>
The first suggestion probably wasn't even worth adding, but hey, you never know right?
I can see the technology-independent Tridion Content Delivery Language (TCDL) link has the following parameters, which are pretty well described on SDL Live Content.
type
origin
destination
templateURI
linkAttributes
textOnFail
addAnchor
VariantId
How do we add multiple attribute-value pairs for the linkAttributes? Specifically, what do we use to escape the double quotes as well as separate pairs (e.g. if we need class="someclass" and onclick="someevent").
The separate pairs are just space delimited, like a normal series of attributes. Try XML encoding the value of linkAttributes however. So, " become "e;, etc...
If you are using some Javascript, you might take care of the Javascript quotes too, as in \".
Edit: after I figured out your real question, the answer is a lot simpler:
You should wrap the values inside your linkAttributes in single quotes. Spaces inside linkAttributes are typically handled fine; but if not, escape then with %20.
If you need something more or want something that isn't handled by the standard tcdl:ComponentLink, remember that you can always create your own TCDL tag and and use a TagHandler or TagRenderer (look them up in the docs for examples or search for Jaime's article on TagRenderer) to do precisely what you want.
My original answer was to a question you didn't ask: what is the format for TCDL tags (in general). But the explanation might still be useful to some, so remains below.
I'd suggest having a look at what format the default building blocks (e.g. the Link Resolver TBB in the Default Finish Actions) output and use that as a guide line.
This is what I could quickly get from the transport package of a published page:
<tcdl:Link type="Page" origin="tcm:5-199-64" destination="tcm:5-206-64"
templateURI="tcm:0-0-0" linkAttributes="" textOnFail="true"
addAnchor="" variantId="">Home</tcdl:Link>
<tcdl:ComponentPresentation type="Embedded" componentURI="tcm:5-69"
templateURI="tcm:5-133-32">
<span>
...
One of the things that I know from experience: your entire TCDL tag will have to be on a single line (I wrapped the lines above for readability only). Or at least that is the case if it is used to invoke a REL TagRenderer. Clearly the tcdl:ComponentPresentation tag above will span multiple lines, so that "single line rule" doesn't apply everywhere.
And that is probably the best advice: given the fact that TCDL tags are processed at multiple points in Tridion Publishing, Deployment and Delivery pipeline, I'd stick to the format that the default TBBs output. And from my sample that seems to be: put everything on a single line and wrap the values in (double) quotes.
I am documenting my code using Shinx. In some files I have mathematical formulas and would like to include a reference to them. Being in the very same file this is not a problem. Using :eq:'reference'.
However, how do you cross reference to a formula from a different file? In my case Sphinx is unable to find the reference.
According to the Sphinx docs here, equation cross-referencing only works within the same document at present. I suggest submitting a bug/feature request to get this changed (assuming there isn't one already).
As a workaround, you can probably use the generic cross referencing syntax by placing a reference label immediately before the equation you want to reference (in the "other" file), like so:
.. _equation_in_other_file:
and then use something like:
:ref:` Link Title <equation_in_other_file>`
in the "current" file to reference it.
(note you need to provide an explicit link title)
It's not quite as elegant, but it should get the job done.