React supports data-* and aria-* attributes on elements. When using the component API, I would guess these attributes could be set just like the rest:
React.DOM.div({style: {...}, dataMyFoo: 'bar'}, ...)
Nope. That doesn't work. The dataMyFoo attribute is silently ignored. I read somewhere that these need to be all lowercase. How about:
React.DOM.div({style: {...}, datamyfoo: 'bar'}, ...)
Again, silently ignored.
Is this possible? If so, what is the secret? I spent quite a while searching without finding the answer.
The answer, it turns out, is to use hyphen-separated all lowercase names for the data attribute, like so:
React.DOM.div({style: {...}, 'data-my-foo': 'bar'}, ...)
Note that you must quote the attribute name in this case, since hyphens are not allowed in identifiers in Javascript.
Related
I'm using Flow types for props in React components. When I'm trying to write something like this:
type Props = {
someArray: Array<number>,
someBoolean: boolean,
right after I type last comma it automatically replace boolean with Boolean from capital letter. Since I need to use primitive here instead of wrapper class, I have to rewrite that letter. However it happens every time, so becoming really irritating.
I suppose that it can be fixed in settings, but I could find only suggestions-related options but not about auto replacing. What am I missing?
In your VS code settings.json you can change editor.acceptSuggestionOnCommitCharacter to false and it would then work
I'm creating a javascript regex to match queries in a search engine string. I am having a problem with alternation. I have the following regex:
.*baidu.com.*[/?].*wd{1}=
I want to be able to match strings that have the string 'word' or 'qw' in addition to 'wd', but everything I try is unsuccessful. I thought I would be able to do something like the following:
.*baidu.com.*[/?].*[wd|word|qw]{1}=
but it does not seem to work.
replace [wd|word|qw] with (wd|word|qw) or (?:wd|word|qw).
[] denotes character sets, () denotes logical groupings.
Your expression:
.*baidu.com.*[/?].*[wd|word|qw]{1}=
does need a few changes, including [wd|word|qw] to (wd|word|qw) and getting rid of the redundant {1}, like so:
.*baidu.com.*[/?].*(wd|word|qw)=
But you also need to understand that the first part of your expression (.*baidu.com.*[/?].*) will match baidu.com hello what spelling/handle????????? or hbaidu-com/ or even something like lkas----jhdf lkja$##!3hdsfbaidugcomlaksjhdf.[($?lakshf, because the dot (.) matches any character except newlines... to match a literal dot, you have to escape it with a backslash (like \.)
There are several approaches you could take to match things in a URL, but we could help you more if you tell us what you are trying to do or accomplish - perhaps regex is not the best solution or (EDIT) only part of the best solution?
I'm creating a custom directive that I want to use to display the value of a field and an optional suffix (expected for units and such). Note that my example is shortened to stay concise.
My template looks something like
<div class="my-value">{{boundValue}}{{boundSuffix}}</div>
For the value, I'm using a two-way binding (=) and for the suffix, I'm using a string binding (&).
It worked great when I bound ° into the suffix to display a temperature, but when I tried to bind in meters (note, there's a leading space - I don't want it pushed up against the number) the leading space seems to get trimmed and my result ends up looking like 123meters.
Using the chrome developer tools, I added a link function and inspected the directive's scope. By the time it reaches the link function, boundSuffix has already been trimmed. It seems like Angular is pulling some shenanigans on my behind the hood. Is there any way for me to avoid this trimming?
It's better to use angular filters to solve your problem. Filters allow to format your output as currency or as UPPERCASE (for example). Try to look here for more info. And here is working example
Example:
.. member:: CK_UTF8CHAR model[16]
Gives me both the type and the name bolded and hyperlink not working.
Practically we are forced to use this cases like that:
.. member:: model
Because otherwise it would be incorrect (use it without array and with the same type).
Well, this seems to be a real bug in Sphinx. I reported that and it was confirmed. I've come up with a little workaround for now, but it's more of a crutch. Just put the following to the layout.html file of your Sphinx theme:
<script>
$('dl.member dt').each(function() {
$(this).find('big:first').text('[')
$(this).find('big:last').text(']')
});
</script>
Now you may use parenthesis instead of brackets in broken structures: model(16) becomes model[16] (and label(\ ) becomes label[], but only within the .. member:: directive.
I know it is not a very elegant solution, but it is OK as a temporary fix, until the bug gets resolved.
I noticed there is a bug in Croogo's NodesController::search() when searching for words with some non-ascii chars on them e.g. 'üäö'. If I search for example for 'Steuergeräte' (german) I get no results, even though I should. If I search for 'Steuergerate' (which would be misspelled in german) I get the desired results. Which is totally weird.
A direct query on the db I works fine:
"SELECT * FROM i18n WHERE content LIKE '%Steuergeräte%';"
Which returns the expected records.
But it's not a general problem with unicode-chars, as for example, searching for a japanese word worked as expected. So this only affect some chars.
Cakephp: 2.4.0, Croogo: 1.4.5
Ok, I found the cause of the problem.
On the search-view, the string to be searched for is cleaned with:
$q = Sanitize::clean($this->request->params['named']['q']);
Which among other things runs html_entities on the string as default, when 'encode' => true is set (default). This would turn e.g. ö into ö and then search for words with html-entities on them.
I got a workaround by doing:
$q = $this->request->params['named']['q'];
// Use encode=false on Sanitize::clean to prevent äüöß etc. getting
// replaced by html entities. And strip tags manually first to prevent
// html injected strings.
$q = strip_tags($q);
$q = Sanitize::clean($q, array('encode' => false));
Note: If like in my case, TinyMCE is set with 'entity_encoding' => 'raw' then the body field in the nodes table would contain äöü instead of htmlentities as well, which IMO is a far better practice as replacing them with htmlentities. Per default though, tinymce replaces chars with htmlentities, so the body field would work with the default search behaviour of Croogo/Cakephp. But searching, for example, in the title-field wouldn't.
Update
Ok, as mark comments suggested, sanitizing and using cake's paginate method, is not necessary, so the Sanitize part can be skipped. I also found using htmlspecialchars even better as strip_tags, as strip_tags wouldn't take care of e.g. '&', and on the body, tinyMCE saves those as html_entities. So the updated code would look like this:
$q = htmlspecialchars($this->request->params['named']['q']);
// go on with searching for nodes on paginate-method