As part of a really large React codebase, we have added a lot of prop type check over the years.
They output a lot of errors when prop type validations fail:
I noticed that in the developer console, I can override the default settings to hide all the errors like below:
and if I do that all the normal errors and these type invalidation errors get hidden.
Is there a way I can hide only the prop-type check errors (by classifying them as some other output type) and keep getting the usual JS errors - to reduce the noise I'm getting and this also causes a lot of vertical scroll which is hard to keep up with and causes the usual console messages to lose sight of.
Solution
you can use filter field provided in developer console
you can filter out error based on their content using regex, simply write -/Failed\s+prop\s+type/ in the filter field.
Explanation
we write regex in between // , we append it with - to indicate that don't show anything that matches the regex, \s+ is used to represent whitespace in regex.
Related
I updated my nVidia drivers and suddenly started getting the following validation error:
VUID-vkCmdDrawIndexed-blendEnable-04727(ERROR / SPEC): msgNum:
-1979288290 - Validation Error: [ VUID-vkCmdDrawIndexed-blendEnable-04727 ] Object 0: handle =
0x5eb05e000000003b, type = VK_OBJECT_TYPE_PIPELINE; | MessageID =
0x8a06751e | vkCmdDrawIndexed: Image view's format features of the
color attachment (0) of the active subpass do not contain
VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT bit, but active
pipeline's pAttachments[0].blendEnable is not VK_FALSE. The Vulkan
spec states: If rasterization is not disabled in the bound graphics
pipeline, then for each color attachment in the subpass, if the
corresponding image view's format features do not contain
VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT, then the blendEnable
member of the corresponding element of the pAttachments member of
pColorBlendState must be VK_FALSE
(https://vulkan.lunarg.com/doc/view/1.3.211.0/windows/1.3-extensions/vkspec.html#VUID-vkCmdDrawIndexed-blendEnable-04727)
Things still render correctly, but I'd like to fix the validation issue.
I am a bit confused as to how I set the VK_FORMAT_FEATURE_COLOR_ATTACHMENT_BLEND_BIT flag or if its part of the format vkGetPhysicalDeviceSurfaceFormatsKHR returns.
If it's the former, how do i set it and if it's the latter, how do i draw to it with blending enabled and not get validation errors?
Thank you!
Format features are not something you set; they're limitations that the Vulkan implementation informs you that you must work within. In particular, format features are properties that restrict how you may use any image with a particular combination of format, tiling, and so forth.
Swapchain images are subject to the same limitations as user-created images. The specification details what the equivalent VkImageCreateInfo would be for a particular vkCreateSwapchainKHR call. So those are the parameters you will need to send to vkGetPhysicalDeviceFormatProperties to see if your implementation supports some particular use of the swapchain image.
Blending is such a use. Apparently, whatever format you used to use allowed blending under the old driver, but this changed. And your code never verified that it was allowed.
Well, I missed another validation error that gave me the clue to find the issue. I had to update the VkApplicationInfo apiVersion to VK_API_VERSION_1_3. Leaving the answer here in case it helps anyone else.
I previously used https://github.com/quilljs/quill/issues/1184#issuecomment-403657128 to make sure that no one can paste formatted text in the QuillJS editor, because I would like people to only use the few editing buttons that I enabled from QuillJs. Since then, it stopped working for me. My question is:
is this working for everyone else?
if no, do you know of an alternative?
One thing about https://github.com/quilljs/quill/issues/1184#issuecomment-403657128 that may behave different than you may have expected could be the 'silent'.
"APIs causing text to change may also be called with a "silent" source, in which case text-change will not be emitted. This is not recommended as it will likely break the undo stack and other functions that rely on a full record of text changes." [ https://quilljs.com/docs/api/#events ]
So if you expected to get the text-change event get emitted but do not get it, then change these two lines
this.quill.updateContents(delta, 'silent')
this.quill.setSelection(index, length, 'silent')
like this:
this.quill.updateContents(delta, 'user')
this.quill.setSelection(index, length, 'user')
Then the text-change event will get fired.
Umbraco uses angularJS as based library and backoffice totally developed on it. The reason telling first is to tell that I have a field on which URL regular expression applied. If someone entered invalid url like below image
it shows error as need.
But if a user try to remove whole text by selecting it and removing at once. It still keep appearing the error like this
However, if a user erase text one by one like this
then the validation error removed and user need to click on button to see error again.
I would to know how screen 3 state can be achievable when user remove all text together? Its really annoying behavior for a user to remove text character one by one to refresh the state of the field. Screen 3 state should be applied on screen 2.
Can anybody tell me how it can fix or achievable? Right now, it seems like a default behavior.
Looking forward to hear from you guys. Suggestions will be much appreciatable.
Regards o
I've looked into this issue. This seems to be a product bug.
When you remove whole text at once, newValue is an empty string and the code responsible for resetting error messages doesn't run. If you have access to the umbraco code, you can easily fix it by removing highlighted check:
I'm trying to make a React instantsearch that lets you search phone numbers. They need to be displayed in this format: "(123)456-7890" but I want to be able to be able to search with either "(123)456-7890" or "1234567890".
I thought I could just store it in the index formatted and then the typo tolerance would take care of non-formatted queries. But I get no results with the query "1234567890". It apparently has to do with the fact that the formatting splits the number into three words and the query is just one word. Bizarrely, this means that adding the parentheses doesn't get you more matching characters on the search, but leaving them out can cause the query not to match at all.
I then tried just storing it as non-formatted (only digits) in the index. This time, both the formatted and unformatted queries got a match. But when typing it in digit-by-digit, the result disappears when I get to "(123)", only reappearing when I get to "(123)456-7". It seems like a frustrating and bizarre user experience to be typing exactly the number the result shows and having it disappear.
I've tried adding the perens to the optional words setting, but that didn't seem to have any effect. I think if I could get Algolia to ignore the perens and dash instead of replacing them with a space, this whole thing wouldn't be a problem. Is there a way to accomplish that? Maybe it's best to find a way to filter the query before it gets sent to Algolia? How should I go about that?
Store 1234567890 in an attribute named phoneNoFormat and (123)456-7890 in an attribute named phoneFormat. Include both in searchableAttributes. On the display side, look in the _highlightResult field to see which attribute matched and render the highlighted result for that attribute. With default typo tolerance each of these queries will match and correctly highlight either one or both of the attributes.
1234567890
123-456-7890
(123)456-7890
(123) 456-7890
(123)4567890
(123) 4567890
Since you're using React InstantSearch, you will need to make your own Hits component, where you can change the attribute name used to display the result on a per-hit basis. Thankfully this is not too complicated. Just see the documentation for connectHits.
When you are looping through the hits, look at each the _highlightResult property of each hit to see which of the two attributes matched. Then, when you create the <Highlight /> component set the attributeName property to the right attribute. So you have this:
<Highlight attributeName='phoneFormat' hit={hit}/>
Or this:
<Highlight attributeName='phoneNoFormat' hit={hit}/>
Okay, this is driving me nuts. I’m working through the IBM CakePHP Tutorial, and in the first part, I’m at the section where the author is introducing validation rules for form input:
www.ibm.com/developerworks/opensource/tutorials/os-php-cake1/section5.html#N107E3
For the life of me, I can’t figure out what’s happening in this line of code:
$this->invalidate('username_unique');
According to the CakePHP documentation, the Model::invalidate() method takes as its first parameter a string that specifiies “The name of the field to invalidate”. How is “username_unique” the name of the field to validate? Looks to me like it should be just plain old “username”. But incredibly enough, the author’s code works, and mine doesn’t when I change “username_unique” to “username” (or even “User.username”), so I’m thinking there might be a serious flaw in the documentation (or very possibly, with me).
[FWIW, I can see that the CakePHP 1.25 provides a better means of doing validation, but I still find it troubling that what seems to be a well-documented method doesn't seem to be doing what it advertises, and I want to understand why the tutorial code works.]
Can anyone shed any light on this?
The "magic" is actually in the $form in this case.
When calling $this->invalidate('username_unique'), Cake takes a note that the field username_unique is invalid. The fact that this field does not actually exist is irrelevant.
Now, take another look at the actual $form field (slightly reformatted):
echo $form->input('username', array(
'after' => $form->error('username_unique', 'The username is taken. Please try again.')
));
It's outputting a normal form field, but "manually" places an error() output after the form field. $form->error('username_unique', $message) means "if there's an error for the field username_unique, output the message $message". So you're actually marking an imaginary field as invalid and are manually outputting an error message for this imaginary field.
And actually, that's a load of outdated cr*p you should forget right away. There's a built-in syntax for multiple validation rules per field, so you can test for character length and uniqueness at the same time and even get different error messages for each error type. There's even a built-in isUnique rule, so you won't even have to code a manual uniqueness test.