Currently, if I do something like const input = getByLabelText('Checked'); The type of input is HTMLElement.
However, if I try to do something like expect(input.checked).toBe(true); or input.value typescript gets sad because it's not of type HTMLInputElement. I'm wondering if I'm missing something or the types need to add a generic to do something like getByLabelText<HTMLInputElement>()
I cast them as an HTMLInputElement, and it could probably be seen as a band-aid fix, but that's what it's for.
I'm a bigger fan of const input = getByLabelText('Input') as HTMLInputElement though, it's easier to see
Related
I am porting a Clojure program to Swift. Being a dynamically typed language, it is easy to throw different values together like this:
(def settings {:total-gens 5
:name "Incredible Program"
:options [:a :b :c :d :e]
:final-comment "Hope you had a good time."})
I pass settings maps like this around in the program, and I wanted to have a fairly similar process in Swift.
Right away, I feel like I am fighting the type system and I'm wondering what is the most elegant way to do this.
Here are two options that were recommended to me, both of which seem verbose or strange:
1) First, make an enum type of all possible settings value types. Then, create a dictionary of String: SettingsEnumType. Every time I need to add a new type of value to my dictionary, I first need to change the enum definition, and then change the actual dictionary.
2) Instead, create an empty protocol with no requirements. Then extend values like Int, String, etc to adopt this protocol, even though it is really a "dummy" protocol. Then make my settings dictionary String : SettingsProtocol so I can add whatever type I want in there (after first extending the type).
Both of these options feel weird to me, like I'm trying to circumvent the type system rather than have it work for me. The second option is frankly silly, but would no doubt work as needed.
Are there any other possibilities for doing something like this? Additionally, would the String type be the only obvious type for the keys in a settings dictionary? In this case, Clojure has again spoiled me with the useful keyword type that simultaneously acts as a look-up function in addition to a value type.
Any advice/pointers appreciated as I consider this new language.
After referring to Array with string and number answer, I believe you can create a Heterogeneous Dictionary with below Syntax:
let heteroDict = Dictionary<Any, Any>()
Can you try this one?
In a friendly chat that I was having with a friend during a code review we notice that in the code there was a lot of:
unknownTypeVal match {
case asStr: String => //DO SOMETHING FOR STRING
case asInt: Integer => //DO SOMETHING FOR Integer
case asMyOwnClass: MyOwnClass => //DO SOMETHING FOR MyOwnClass
}
problem that was initially generated by methods that return Any or Option and there is no way to remove that because we are using libraries as XPath, and JSONPath, which return instances of Any or Option for a provided path.
I don't want to get into discussions of "preference", this is not an opinion question, I want to know either by standard defined preferably by Scala, or any other organization of impact, to do this kind of "type checking" in code in a more organized way, we think that this functionality can be reduced to a single function call to a method which contains a map of function and based on "something" (name of the class or something else that I do not know right now) determine how to process such parameter:
process(myAnnonimusVal: Any) = myMapOfFunct(myAnnonimusVal.getClass) //and based on the function that this will return execute such function pasing myAnnonimusVal
what is encouraged to do by Scala devs or Scala community
In principle, match is the cleanest way to execute code conditional on matching the Any type to something else. Any chain of if-else, instanceOf, etc is bound to turn out to be even more cumbersome and less elegant. A possible exception is a case where you know what the actual type is and can act accordingly, where a direct cast might be permissible.
That said, if you find yourself making the same matches many times, you might as well encapsulate the match in order to avoid code repetition. A partial function might be exactly what you have in mind here.
This is a really silly question, but how can you do convenient formatting of log strings in Play Framework 2 (and in Scala?).
I've googled but its very difficult to find an example, essentially most links are talking about configuring Logback in the first place which I've done fine.
I'm basically trying to find the best stylistic way to do something like:
if(Logger.isDebugEnabled)
Logger.debug("Modified: Id = '" + real_session_id + "', Modified = " + modified.toString)
Coming from a C# background (and log4net) I'd assume you could do something like:
if(Logger.isDebugEnabled)
Logger.debug("Modified: Id = '{0}', Modified = {1}", real_session_id, modified.toString)
But I can't see how this would work with the trait the way it is defined. I've also seen vague references to how you might be able to avoid checking Logger.isDebugEnabled by using a lazy evaluative syntax like:
Logger.debug("Modified: Id = ${real_session_id}, Modified = ${modified.toString}")
That uses Scala macros - but again, that doesn't work and I can find very little information about it.
Am I missing something really blatant here?
The framework used for logging is logback. When you type : Logger.debug, the isDebugEnabled is already implicitly checked.
For the syntax of logging, use the Scala string interpolation.
Logger.debug(s"Modified: Id = '$real_session_id', Modified = $modified.toString")
Why not just use the standard String interpolation capabilities of the language/stdlib? http://docs.scala-lang.org/overviews/core/string-interpolation.html
I apologise if I've missed something crucial about your question.
As to avoiding the if (Logger.isDebugEnabled) check, if the logging framework is not providing some sort of lazy evaluation scheme for arguments passed into it, I would just first consider defining my own wrappers:
object MyLazyLogger {
def debug(msg: => Any) =
if (Logger.isDebugEnabled) Logger.debug(msg)
}
Also, I don't think the way in which you interpolate stuff into the string has anything to do with not evaluating the arguments to debug() if logging is disabled—if debug() declares that it eager-evaluates any arguments passed into it, there's no way that I can see you can change to lazy evaluation at the call site by just using a "special form" of string interpolation. (I'd be happy if anyone proved me wrong here and taught me something new :))
Disclosure: I'm not familiar with Play (yet), so I'm just taking a shot at a general approach here.
I am trying to handle a simple case where i could be getting an object, or a dictionary. So i am either going to get a object like:
obj.fields.nick
or its going to be a dictionary like
obj['nick']
I was wondering if there was a simpler way to do the following:
value = (eval("obj.fields." + field[1]) if obj?.fields ) ? eval("obj['#{field[1]}']")
I was hoping to do something like:
value = (obj?.fields?."#{field[1]}" ) ? eval("obj['#{field[1]}']")
But if that worked I wouldn't be writing this post...
I am basically looking for a way to execute a string as part of the if
value = obj.fields?[field] ? obj[field]
# or
value = (obj.fields ? obj)[field]
This is the same as
if obj.fields?
obj.fields[field]
else
obj[field]
There is absolutely no need for eval.
The string interpolation construct ("Equals four: #{2+2}") is something that is handled by the coffeescript compiler, and will therefore not work inside an eval. But assuming the naming of the stuff inside the string does not change, you could easily rewrite it, so that eval("obj['#{field[1]}']") becomes eval("obj['"+field[1]+"']"). Assuming I got your question right of course.
I'm currently studing symfony framework.
and I could not found the answer of how different between $_GET and $request->getParameter().
I can understand the $request->getPrameter() can be used for,
if(isset($_GET['test'])){
$test = $_GET['test'];
}else{
$test = 'Unknown';
}
to
$request->getParameter('test','Unknown');
and anything else? I was expect it filter XSS but I think it doesn't.
For me, $_GET way is much easier, but I feel like I should use the $request->getParameter()
So, I'd like to know exactly how diffrence.
Thanks! :)
Use:
$request['parameter']
This is equivalent to $request->getParameter('parameter', null).
Note that $request->getParameter differs from $_GET in that it returns all parameter types. $request->getGetParameter is equivalent to $_GET.
If you access a request parameter like:
$request->getParameter('parameter');
it can be the value of $_GET['parameter'] or $_POST['parameter'] as well. It is useful as normally you don't care whether the value is coming through post or get method.
You should infact be using $request->getGetParameter('parameter') if you're specifically after a get parameters.
$request->getGetParameter('parameter') is the equivalent of $_REQUEST['parameter'] which may not result in the desired behaviour.
Also worth noting that the sfWebRequest object is available in your views via $sf_request i.e. $sf_request->getGetParameter('parameter')