I'm using sinon to stub an instance of express-Request.
It looks something like this:
let req = sinon.createStubInstance(Request);
My method accepts req: Request but my IDE complains about me using SinonStubbedInstance<Request> rather than Request.
I've tried using req as Request but I still get a warning about 'may be a mistake' and that I should first cast to unknown and only then to Request.
I actually don't need anything from this parameter so I really just want to stub it quickly and easily.
When using it in the call to your method, just cast it:
myMethod(req as any);
I understand that this was posed 3 years ago, but since the only answer given is wrong, I feel obliged to comment, for someone else might benefit from it.
It's strongly discouraged to use as any and your compiler should complain about this (unless you have a very good reason not to, you should use strict compiler option).
Casting to unknown and then to your type seems unintuitive, but it is a cleaner way than casting to any. If you use any you might be better off not using typescript at all.
https://www.typescriptlang.org/docs/handbook/declaration-files/do-s-and-don-ts.html#any
Consider doing
let req: SinonStubbedInstance<Request> & Request = sinon.createStubInstance(Request);
instead.
P.S.: Also, the use of let seems suspicious (sure cannot use const?), but that's a different topic.
Related
When moving my functions to .net5 I faced the fact that POCO binding that worked fine with 3.1 is not applicable with .net 5 anymore for some reason. They say it will be implemented at some point maybe, but for the certain reasons I need it now. Tried to find some hacky way to implement this, but failed. The best thought I had was to implement explicit operator in my DTO object which will cast HttpRequestData to it's type, but the problem is that HttpRequestData is an abstract type, and it's concrete implementation type is internal. After that I tried to cast the input parameter to HttpRequestData in middleware with reflection, but parameters are stored in IReadOnlyDictionary which is immutable. So I ran out of ideas now. Maybe someone found workaround to this and can kindly share, would be much appreciated.
I suppose you're using the "dotnet-isolated" mode (only way to run on .NET 5).
I'm trying to find a more elegant solution to this as well.
Meanwhile, what I did was to deserialize the data myself, inside the function.
var body = await new StreamReader(request.Body).ReadToEndAsync();
var myobject = JsonSerializer.Deserialize<MyPocoClass>(json);
I would really prefer if the runtime did it by itself, but I couln't find a way yet. I read somewhere that it is possible to create our own binding code, but I haven't tried it.
I noticed that I could bind to individual properties of the json payload, but not to an object...
I hope this arrives in Azure Functions v4 + .NET6, since it is right around the corner.
I'm pretty new to typescript and I faced the issue with extending the Request type. I actually found a solution, but it doesn't feel right to me, and seems like there might be a better way.
First, the structure. I have a middleware checkAuth that checks the Bearer token, finds the user in the database (or creates one, in case it's the first time) and adds user to the req variable.
Most people recommend modifying the Express' Request type with custom declarations. I don't like this idea, because that will put user object into all requests, even before I actually save user into req.
Another solution is what I use now:
interface ReqWithUser extends Request {
user?: {
...
}
}
This allows me to declare req: ReqWithUser. But there's a flaw. When I try to access req.user, typescript is telling me that it's possibly undefined. Well, that's exactly what I declared with user?:. If I don't put a question mark there, then typescript is mad in router, saying Property 'user' is missing in type Request. That's fair. One of the solution is to use req!.user. Solves all problems, but it still feels imperfect to me. I know the req.user is there, it's not optional, otherwise checkAuth would fail and return 401. If it didn't, the user is there. What feels like the right solution is somehow modify the req type after the checkAuth middleware. Because that's when user is added into the req. Is it possible?
The issue has nothing to do with your types, but it's the fact that Express will always emit Request and not RequestWithUser.
So in your middleware function, you will always get a Request. The only reason RequestWithUser is acceptable is because you made it optional.
Truth is the middleware / decorator pattern doesn't work that well with express. You have a few options (some of which you mentioned)
Use declaration merging to 'patch' the built-in Request. You already mentioned you don't like this though, because it's a bit of a hack.
Don't use Express' middleware system and instead write something that understands how types change with decorators. I don't know exactly what this looks like, or if this has been done before.
Whenever you want to use RequestWithUser in your controllers/middlewares start off with an assertion function to ensure that user exists (allowing you to make it non-optional).
Cast to RequestWithUser, when you need it.
All these options have drawbacks:
You don't like for the reasons mentioned. It's not always 'accurate' so you are sort of lying to Typescript for convenience.
Sounds hard to do
Requires the use of an assertion function, which means you need to do a little extra work every time you want to use the user property. This work is not needed because you as developer know.
You probably don't like casting for the same reason you don't like to use declaration merging.
By far I think 2 is the best solution, because it gives you the advantage of typing without any hacks and without having to do the extra work of an assertion function (which happens during runtime). But it means abandoning Express' Middleware system. I wouldn't know exactly how to write this code, but I am curious how if it can be done...
FYI I opened another stack overflow question, because I am curious:
Typescript typing for decorator middleware patterns
If I create my httpBuilder as shown below (assume that a proxyUsername IS set, so setCredentials is called), then calls to httpAddress-es that are passed in properly are routed through the proxy. However, the Application has some http calls that are within the local network. Can http.nonProxyHosts be used to work around this and bypass the Proxy? If so, how? Use System.setProperty? Or something on HttpBuilder?
HTTPBuilder httpBuilder = new HTTPBuilder(httpAddress)
httpBuilder.setProxy(webProxyHost, webProxyPort, webProxyProtocol)
if (proxyUsername) {
httpBuilder.client.getCredentialsProvider().setCredentials(
new AuthScope(webProxyHost, webProxyPort),
new UsernamePasswordCredentials(proxyUsername, proxyPassword))
}
}
In the code above, all of the various named elements (webProxyHost, etc) are declared as String and set accordingly.
In answer to the question in the above comment, our primary 'nonProxyHost' need was for 'localhost' which is there by default. Thus this ceased to be an issue. Did not ever really find out how to accomplish this as it is somewhat version-specific on HttpClient.
You can set the System property:
System.setProperty('http.nonProxyHosts', myNonProxyHosts)
However, if you call 'setProxy' on HttpBuilder, even if you call 'useSystemProperties' it will not. This is in their documentation, just not obvious!
Finally, you might be able to call:
httpBuilder.client.params.setParameter('http.nonProxyHosts', myNonProxyHosts)
But I do not know for sure if that is the property name and documentation of those properties is hard to find. Worse - those 'params' are deprecated - you are supposed to use the better 'config' classes, though once again finding comprehensive documentation on all the parameters for that is not the easiest! Wish I could have been of more help!
a few days ago i posted a question about Serializing the ResponseStatus property with BinaryFormatter. Mythz pointed out it wasnt the fastest way to go, so i decided to switch to another formatter. Tried ProtoBuff and MsgPack, and am on ProtoBuf now.
My real question is: im trying to grasp how Protobuf knows how ServiceStack Dto's should be serialized. I tried adding all the possible attributes to my existing dto, ProtoContract and ProtoMember(0,1,2,3,etc), but also DataContract and DataMember.
On top of that i dont use ServiceStack's own client, but try to serialize the request to an existing stream.
If i dont do this:
ServiceStack.ProtoBuf.ProtoBufFormat.Model.Add (typeof(NameSpacePlaceholder.Service.Dto.GetNodes), false);
i get an error about Types and Contracts that cannot be infered,
If i do add that piece of code, all continues great, but the deserialized object is empty.
Im using this to Serialize:
ServiceStack.ProtoBuf.ProtoBufFormat.Model.Serialize (ms, myObject);
and to Deserialize:
ServiceStack.ProtoBuf.ProtoBufFormat.Model.Deserialize (ms, null, deserializationType);
I think im missing something here. Could it have something to do with namespaces? I looked into some code from ServiceStack.ProtoBuff, it isnt so hard to understand, but i cannot get it going.
Things that are unclear to me now:
Is there a need to add Attributes to the existing DTO's ? (in ProtoBuf V2 i can also do it in code, i read, but for now i can also alter the existing DTO's)
Do i need to initialize the Request(and response) DTO's, in my Client(Serialize) as wel in my Server(Deserialize)
Is there some reason why i should not be serializing to my own Stream ?
Many thanks,
I hate it to post an answer myself, it means i havent searched enough in the first place
I learned the following attributes are very important:
[ProtoContract]
[ProtoMember(X)]
[ProtoInclude(X,typeof(DerivingClass))]
For now i learned something new: why class inheritance in DTO's is not advisable.
I've got it going now, and will try to make it real-life friendly..
I am wondering if there is a way to ignore certain TypeScript errors upon compilation?
I basically have the same issues most people with large projects have around using the this keyword, and I don't want to put all my classes methods into the constructor.
So I have got an example like so:
TypeScript Example
Which seems to create perfectly valid JS and allows me to get around the this keyword issue, however as you can see in the example the typescript compiler tells me that I cannot compile that code as the keyword this is not valid within that scope. However I don't see why it is an error as it produces okay code.
So is there a way to tell it to ignore certain errors? I am sure given time there will be a nice way to manage the this keyword, but currently I find it pretty dire.
== Edit ==
(Do not read unless you care about context of this question and partial rant)
Just to add some context to all this to show that I'm not just some nut-job (I am sure a lot of you will still think I am) and that I have some good reasons why I want to be able to allow these errors to go through.
Here are some previous questions I have made which highlight some major problems (imo) with TypeScript current this implementation.
Using lawnchair with Typescript
Issue with child scoping of this in Typescript
https://typescript.codeplex.com/discussions/429350 (And some comments I make down the bottom)
The underlying problem I have is that I need to guarantee that all logic is within a consistent scope, I need to be able to access things within knockout, jQuery etc and the local instance of a class. I used to do this with the var self = this; within the class declaration in JavaScript and worked great. As mentioned in some of these previous questions I cannot do that now, so the only way I can guarantee the scope is to use lambda methods, and the only way I can define one of these as a method within a class is within the constructor, and this part is HEAVILY down to personal preference, but I find it horrific that people seem to think that using that syntax is classed as a recommended pattern and not just a work around.
I know TypeScript is in alpha phase and a lot will change, and I HOPE so much that we get some nicer way to deal with this but currently I either make everything a huge mess just to get typescript working (and this is within Hundreds of files which I'm migrating over to TypeScript ) or I just make the call that I know better than the compiler in this case (VERY DANGEROUS I KNOW) so I can keep my code nice and hopefully when a better pattern comes out for handling this I can migrate it then.
Also just on a side note I know a lot of people are loving the fact that TypeScript is embracing and trying to stay as close to the new JavaScript features and known syntax as possible which is great, but typescript is NOT the next version of JavaScript so I don't see a problem with adding some syntactic sugar to the language as people who want to use the latest and greatest official JavaScript implementation can still do so.
The author's specific issue with this seems to be solved but the question is posed about ignoring errors, and for those who end up here looking how to ignore errors:
If properly fixing the error or using more decent workarounds like already suggested here are not an option, as of TypeScript 2.6 (released on Oct 31, 2017), now there is a way to ignore all errors from a specific line using // #ts-ignore comments before the target line.
The mendtioned documentation is succinct enough, but to recap:
// #ts-ignore
const s : string = false
disables error reporting for this line.
However, this should only be used as a last resort when fixing the error or using hacks like (x as any) is much more trouble than losing all type checking for a line.
As for specifying certain errors, the current (mid-2018) state is discussed here, in Design Meeting Notes (2/16/2018) and further comments, which is basically
"no conclusion yet"
and strong opposition to introducing this fine tuning.
I think your question as posed is an XY problem. What you're going for is how can I ensure that some of my class methods are guaranteed to have a correct this context?
For that problem, I would propose this solution:
class LambdaMethods {
constructor(private message: string) {
this.DoSomething = this.DoSomething.bind(this);
}
public DoSomething() {
alert(this.message);
}
}
This has several benefits.
First, you're being explicit about what's going on. Most programmers are probably not going to understand the subtle semantics about what the difference between the member and method syntax are in terms of codegen.
Second, it makes it very clear, from looking at the constructor, which methods are going to have a guaranteed this context. Critically, from a performance, perspective, you don't want to write all your methods this way, just the ones that absolutely need it.
Finally, it preserves the OOP semantics of the class. You'll actually be able to use super.DoSomething from a derived class implementation of DoSomething.
I'm sure you're aware of the standard form of defining a function without the arrow notation. There's another TypeScript expression that generates the exact same code but without the compile error:
class LambdaMethods {
private message: string;
public DoSomething: () => void;
constructor(message: string) {
this.message = message;
this.DoSomething = () => { alert(this.message); };
}
}
So why is this legal and the other one isn't? Well according to the spec: an arrow function expression preserves the this of its enclosing context. So it preserves the meaning of this from the scope it was declared. But declaring a function at the class level this doesn't actually have a meaning.
Here's an example that's wrong for the exact same reason that might be more clear:
class LambdaMethods {
private message: string;
constructor(message: string) {
this.message = message;
}
var a = this.message; // can't do this
}
The way that initializer works by being combined with the constructor is an implementation detail that can't be relied upon. It could change.
I am sure given time there will be a nice way to manage the this keyword, but currently I find it pretty dire.
One of the high-level goals (that I love) in TypeScript is to extend the JavaScript language and work with it, not fight it. How this operates is tricky but worth learning.