I'm fairly new to Typescript.
I have 2 microservices, let's call them ManagerMs and HandlerMs.
They communicate through RabbitMq.
Each of their public methods, becomes a queue on Rabbit when service starts.
The ManagerMs need to preform an RPC call on a function, called 'handle' that belongs to HandlerMs.
Ideally, I want ManagerMs to be able to import just the declarations of HandlerMs so that it can do something like (inside the ManagerMs class):
import HandlerMsApi from '<path-to-declaration-file?>'
...
class ManagerMs {
...
this.rpcClient.call(HandlerMsApi.handle.name) // instead of: this.rpcClient.call('HandlerMsApi.handle')
The point is that a certain service will have access to the declaration of another service and not the implementation.
Currently, both services can't import each other because of the way the project is structured.
So I thought of creating a shared library which will hold just the declaration files of the different modules, but that mean that .d.ts files aren't located next to their corresponding implementation files (.ts).
Questions are:
Is it a good idea?
How can I achieve such behaviour?
Currently, when I tried to do so I have the following .d.ts file (in a different folder than the implementation):
declare class HandlerMsApi {
handle(req: string): Promise<any>;
}
export = HandlerMsApi;
But when I try to compile (tsc) my code I get the following error:
"....handler.d.ts' is not a module"
Any help?
Related
I have a servicereference with a method I need to use in a test.
The servicereference class is defined as:
public class MyServiceReference : Clientbase<IMyServiceReference>, IMyServiceReference
{
public MyServiceReference()
{
}
..... methods is then defined
}
From my testmethod I have tried both
private MyServiceReference myServiceReferenceFake = A.Fake<MyServiceReference>();
// And
private MyServiceReference myServiceReference = new MyServiceReference();
For both of these is crashes in the constructor with the message:
System.InvalidOperationException: Could not find default endpoint element that references contract.
All I need is to have a callto definition from a method in that class.
How can this be solved?
I've no experience with Clientbase, which I assume to be a System.ServiceModel.ClientBase<TChannel>,but I can make some general comments.
Since you tried first to fake a MyServiceReference, I'll assume that you're not testing that class, and you want to use it as a collaborator for the system under test. In that case, your best bet is to try faking IMyServiceReference. interfaces are very easy to fake, since they don't bring along any behaviour or baggage like faking a class does.
If you feel you really need to fake a MyServiceReference, then we have to contend with the fact that FakeItEasy will eventually call MyServiceReference(), which will call ClientBase<IMyServiceReference>(), whose documentation says
Initializes a new instance of the ClientBase<TChannel> class using the default target endpoint from the application configuration file.
Based on the error you reported, I assume that the application configuration file is not found or does not include the configuration required to create a MyServiceReference. The fact that you get the same error when you just try to instantiate a MyServiceReference directly strengthens my belief.
So I think your paths forward are either to try faking IMyServiceReference or to provide the configuration that ClientBase<IMyServiceReference> needs.
How can I instantiate a class (with, say, a known empty constructor), for example:
at api/EmptyClass1.ts, I have:
export default class EmptyClass1 {
}
and, at api/EmptyClass2.ts, I have:
export default class EmptyClass2 {
}
I want this function:
function(filepath:string):any{
return Object.fromFile(filepath); //this line is mock code
}
to return a new instance of either EmptyClass1 or EmptyClass2, if the parameter filepath:string is "api/EmptyClass1.ts" or "api/EmptyClass2.ts", respectively.
The files defining the classes may not be known at the time the function is written may include any number of files. Consequently, using the import statement for each class, then using a switch, or if-then statements is not an acceptable solution.
The .ts files defining the classes are transcoded to javascript and reside in the application .build folder as .js files.
I am using typescript on node.js (recent versions).
Use require instead, and your problem will be solved. If the file may not exist, you can use optional-require if you want to have a fallback without using try/catch.
function fromFile(filepath:string):any{
// return Object.fromFile(filepath); //this line is mock code
return require(filepath);
}
Or just call require directly instead of wrapping it in another function.
Also check:
nodejs require inside TypeScript file
I encountered some problems reading the Rust documentation:
In this example, we have three modules again: client, network, and network::client. Following the same steps we did earlier for extracting modules into files, we would create src/client.rs for the client module. For the network module, we would create src/network.rs. But we wouldn’t be able to extract the network::client module into a src/client.rs file because that already exists for the top-level client module! If we could put the code for both the client and network::client modules in the src/client.rs file, Rust wouldn’t have any way to know whether the code was for client or for network::client
Why does Rust need to know the code in client.rs belongs to client or network::client? Can it belong to both?
The compiler has rules about where the source file for an external module can be. Those rules ensure that there aren't two modules that use the same source file.
If you really want to, you can override the rules with a #[path] attribute:
mod client; // defaults to client.rs relative to the current file
mod network {
#[path="client.rs"] // reads the same source as the outer `mod client;`
mod client;
}
However, doing so would lead to duplicate code, i.e. the code in client.rs would be compiled twice, and everything that's defined in client.rs would be defined twice, in two separate modules. It's as if you made network/client.rs an exact copy of client.rs and didn't write the #[path] attribute.
Another thing you can do is provide an alias for a module by reexporting it elsewhere. This can be useful when building a library: it enables you to present an external module hierarchy that is different from the internal module hierarchy.
mod client; // not accessible externally
pub mod network {
pub use client; // network::client::* will refer to the same definitions as client::*
}
For example, with the above, the client module is defined in client.rs, but clients use it through my_crate::network::client.
On some of my projects, I use the double dispatch mechanism to provide at run time a "view" of my infrastructure module to my domain module (Strengthening your domain: The double dispatch pattern). What I call 'modules' above is simply separate jar files where the dependency from service.jar->domain.jar is enforced at compile time only. Will I be able to have this working on java-9 if I define my service and domain as 'true' java 9 modules?
module domain
L Fee.java
L Payment recordPayment(double, BalanceCalculator)
L BalanceCalculator.java
module service
L BalanceCalculatorImpl.java // implements BalanceCalculator
L double calculate(Fee fee) //call fee.recordPayment(amount,this)
Yes that is possible. Here are some things to consider:
The module domain needs to export the package containing Fee. Possibly to everyone but at least to service.
The module service will have to require domain as BalanceCalculatorImpl has to access BalanceCalculator since it implements it.
It looks like clients of service need to know about domain as well, which is a textbook case for implied readability.
In a simple setup either service or some third module will have to instantiate BalanceCalculatorImpl and pass it to Fee, this can not happen in domain or it would create a cyclic dependency.
A more advanced solution would be services, where all code that can access BalanceCalculator, even inside domain, can get hold of all its implementations.
Taking all of these into account, this is what the two module declarations might look like:
module com.example.domain {
// likely some requires clauses
// export packages containing Fee and BalanceCalculator
exports com.example.domain.fee;
exports com.example.domain.balance;
}
module com.example.service {
requires public com.example.domain;
// likely some more requires clauses
// expose BalanceCalculatorImpl as a service,
// which makes it unnecessary to export the containing package
provides com.example.domain.balance.BalanceCalculator
with com.example.service.balance.BalanceCalculatorImpl;
}
Then every module that likes to use BalanceCalculator can declare it in its module declaration with uses com.example.domain.balance.BalanceCalculator and get instances of that using Java's ServiceLoader.
You can find more practical applications of the module system (particularly for services] in a demo I created.
(Note: The answer was revised after this exchange.)
Currently I am trying to use TypeScript to create JavaScript-Files which are then required in a index.js file. I am using VS 2015 Update 3 with node.js tools 1.2 RC. Sadly it is not working like I thought it would.
To begin with here is my initial idea:
I have a node module (to be precise, it is a deployd module http://docs.deployd.com/docs/using-modules/). This module is handling payment providers like paypal or stripe. Now I want to use TypeScript to write interfaces, classes and use types to make it easier to add new payment providers. The old .js files should still be there and used. I want to migrate step by step and use the self-written and compiled .js files together. So I thought I can create .ts files, write my code, save, let VS compile to js and require the compiled js file in another js file. Okay, that is my idea... Now the problem
I have a PaymentProvider.ts file which looks like this
import IPaymentProvider = require("./IPaymentProvider.ts"); // Interface, can't be realized in JavaScript, just TypeScript
export abstract class PaymentProvider implements IPaymentProvider.IPaymentProvider
{
providerName: string;
productInternalId: number;
constructor(providerName : string)
{
this.providerName = providerName;
}
//... some methods
};
The other file is PaypalPaymentProvider.ts
import PaymentProvider = require("./PaymentProvider.ts");
export class PaypalPaymentProvider extends PaymentProvider.PaymentProvider
{
constructor()
{
super("paypal");
}
// more methods
}
VS 2015 doesn't show any errors. The js and .js.map files are generated. Now I thought I could require the files and that's it. I tried to use the PaypalPaymentProvider.js like this const PaypalPaymentProvider = require("./lib/payment-provider/PaypalPaymentProvider.js"); (yes, it is located there) but it's not working. When starting the index.js via node I get the following error:
...\Path\PaymentProvider.ts:1 (function (exports, require, module, __filename, __dirname) { import IPaymentProvider = require("./IPaymentProvider.ts"); Unexpected token import....
I find it strange that this is the error, because JavaScript doesnt't have Interfaces. The compiled IPaymentProvider.js is empty.
Also I thought that TypeScript is mainly for development and the compiled JavaScript for production. So why it is requiring a ts-file? I thought imports in typescript will be converted to require of the compiled js-file?
Do I need to require all compiled js files and not only the one I currently try to use? (I don't think so...)
To be honest, I think the main problem is that I am new to TypeScript and make something wrong from the very beginning.
Any help/advice? Thanks!
I have the solution... Thanks to Paelo's links I was able to see that I need to omit the file ending! So the really simple solution was to write
import IPaymentProvider = require("./IPaymentProvider");
instead of
import IPaymentProvider = require("./IPaymentProvider.ts");
When I changed that in every ts file it worked perfectly!