I'm currently working on my telegram testing in firebase and I encountered an issue with lint, is there someone that encountered same issue as mine?
ERROR
/root/1telegram/functions/src/index.ts
26:11 error Identifier 'chat_id' is not in camel case camelcase
27:12 error Identifier 'first_name' is not in camel case camelcase
31:7 error Identifier 'chat_id' is not in camel case camelcase
32:22 error Identifier 'first_name' is not in camel case camelcase
Camel case refers to removing all spaces and underscore, and capitalizing all words but the first one.
E.g. chat_id becomes chatId and first_name becomes firstName
If this doesn't work, try to capitalize the first word as well (e.g. FirstName); this naming convention (pascal case) is sometimes used interchangeably with camel case.
I hope this helps!
Related
I am using Yup and Formik for my registration form. Somehow when using the trim method provided by Yup on my password there is no error message appearing, while all the other validation methods are working properly.
Here is the password part of my Yup schema:
password: Yup.string()
.required('Password is required)
.min(8, 'Password must be at least 8 characters long')
.max(18, 'Password cannot be longer than 18 characters')
.matches(
/^(?=.*[a-z])(?=.*[A-Z])(?=.*[0-9])(?=.*[!##\$%\^&\*])/,
'Password must contain at least one number as well as one uppercase, lowercase, and special character'
)
.trim('Password cannot include leading and trailing spaces')
.matches(
/^(?!.* )/,
'Password cannot contain two or more consecutive spaces'
)
The validation must be run in strict mode, otherwise the trim-method will transform the input instead of validating it. If strict is added it will check if there are leading or trailing spaces. Additionally, I found out that it can lead to bugs if type email is used in the html input field. The test-method and also the trim-method did not work when type email was set.
According the CSS Level 3 specification, for parsing the start of an identifier, you:
Check if three code points would start an identifier
Look at the first code point:
If the first character is -, then we have a valid identifier if:
The second code point is an identifier-start code point ([a-zA-Z_] or non-ASCII).
The second code point is -.
The second and third character form a valid escape.
Otherwise, we do not have a valid identifier start. After determining if we have a valid identifier start, the only requirements to have a valid <ident-token> is we have 0 or more of any combination of the following:
Escape tokens
ASCII letters
Digits
_ or -
Non-ASCII characters
Since we do not require any characters following an identifier start token, this would suggest that -- is a valid identifier, even if never supported by any browser or framework. However, even official CSS validation services (maintained by those that design the CSS specifications) do not consider this a valid identifier. Is this merely a bug in the validation service?
Yes it's valid and it works. It's the shortest custom property (aka CSS variable) that you can define:
body {
--:red;
background:var(--);
}
Related: Can a css variable name start with a number?
The -- custom property identifier is reserved for future use, but current browsers incorrectly treat it as a valid custom property.
See also
w3c/csswg-drafts#6313
I know that URI supports the following syntax:
http://[user]:[password]#[domain.tld]
When there is no password or if the password is empty, is there a colon?
In other words, should I accept this:
http://[user]:#[domain.tld]
Or this:
http://[user]#[domain.tld]
Or are they both valid?
The current URI standard (STD 66) is RFC 3986, and the relevant section is 3.2.1. User Information.
There it’s defined that the userinfo subcomponent (which gets followed by #) can contain any combination of
the character :,
percent-encoded characters, and
characters from the sets unreserved and sub-delims.
So this means that both of your examples are valid.
However, note that the format user:password is deprecated. Anyway, they give recommendations how applications should handle such URIs, i.e., everything after the first : character should not be displayed by applications, unless
the data after the colon is the empty string (indicating no password).
So according to this recommendation, the userinfo subcomponent user: indicates that there is the username "user" and no password.
This is more like convenience and both are valid. I would go with http://[user]#[domain.tld] (and prompt for a password.) because it's simple and not ambiguous. It does not give any chance for user to think if he has to add anything after :
I ended up writing a parser for a small subset of SQL.
The grammar has a lot of regular tokens (SELECT, CREATE, ...) and a few more general (e.g. S_GEN_IDENTIFIER matches [A-Z_.\d]|\"(~[\n, \r, \"])*\").
The problem is, "SELECT col AS type ..." doesn't get parsed since instead of <S_GEN_IDENTIFIER> "type" column alias is matched as <T_TYPE>.
I had an idea to replace token with a rule with the same name and check is the token of interest lies within some token range (something like [<T_AS> - <T_KEEP_DUPLICATES>]. Unfortunately it turned out that the syntax for tokens and rules differs so I can't do it.
I could just copy-paste all tokens inside the new rule but I don't want to do it for obvious reasons.
Is there any way to check if token lies within the range of predefined tokens?
Perhaps you could treat "type" as an unreserved keyword. Then you can follow the advice of question 4.19 of the FAQ
http://www.engr.mun.ca/~theo/JavaCC-FAQ/javacc-faq-moz.htm#tth_sEc4.19
What I don't really understand is the benefit of using '?' instead of '&' in urls:
It makes nobody's life easier if we use a different character as the first separator character.
Can you come up with a reasonable explanation?
EDIT: after more research I found that "&" can be a part of file name (terms&conditions.html) so "?" is a good separator. But still I think using "?" for separators makes lives easier (from url generators and parsers point of view):
Is there any advantage in using "&" which is not clear at the first glance?
From the URI spec's (RFC 3986) point of view, the only separator here is "?". the format of the query is opaque; the ampersands just are something that HTML happens to use for form submissions.
The answer's pretty much in this article - http://www.skorks.com/2010/05/what-every-developer-should-know-about-urls/ . To highlight it, here goes :
Query is the preferred way to send some parameters to a resource on
the server. These are key=value pairs and are separated from the rest
of the URL by a ? (question mark) character and are normally separated
from each other by & (ampersand) characters. What you may not know is
the fact that it is legal to separate them from each other by the ;
(semi-colon) character as well. The following URLs are equivalent:
http://www.blah.com/some/crazy/path.html?param1=foo¶m2=bar
http://www.blah.com/some/crazy/path.html?param1=foo;param2
The RFC 3896 (https://www.ietf.org/rfc/rfc3986.txt) defines general and sub delimiters ... '?' is a general, '&' and ';' are sub. The spec is pretty clear about that.
In this case the latter '?' chars would be treated as part of the query. If the query parser follows the spec strictly, it would then pass the whole query on to the app-destination. If the app-destination could choose to further process the query string in a manner which treats the ? as a param name-value pairs delimiter, that is up to the app's designers.
My guess is that this often 'just works' because code that splits query strings and the original uri uses all delimiters for matching: 1) first query is split on '?' then 2) query string is parsed using char match list that includes '?' (convenience only).... This could be occurring in ubiquitous parsing libraries already.