The Problem
I am importing a class in two related projects. It appears that the prototype chain of a class instance created in one project does not match the version of the class in the other project.
Specifically, instanceof returns false.
The Code
I have three npm packages / projects (names invented for simplicity):
classes (contains Payload)
processors (contains ProcessPayload); depends on classes
main (not actually a package); depends on classes and processors
The main project creates a Payload and passes it to a ProcessPayload object.
To be clear: these projects have three separate package.json and any associations between them are done via dependencies.
main/index.js
import { Payload } from 'classes'
import { PayloadProcessor } from 'processors'
const payload = new Payload()
const processor = new PayloadProcessor()
console.log(payload instanceof Payload) // true
processor.process(payload)
The ProcessPayload object imports Payload and uses it to validate the type of its parameters.
processors/PayloadProcessor.js
import { Payload } from 'classes'
class PayloadProcessor {
process = (obj) => {
console.log(obj instanceof Payload) // false
}
}
export default PayloadProcessor
The Question
What is going on with the prototype chains here. I plan to use duck typing and create an isPayload method to solve my problem, but are there really two versions of Payload floating around in my dependency stack? Is there any way to get instanceof to work as expected in this situation?
Related
I am writing a node app in typescript. I have written a class decorator #myDecorator, and the purpose of #myDecorator is such that I need to keep track of all the classes to which it's applied.
My question: how do I make sure all of those decorated classes are loaded before making use of that behavior? Some example code will help to make this more concrete:
Declaration of the decorator in file myDecorator.ts:
type ConstructorType = { new (...args: any[]): any };
// keep track of decorated classes
const registeredClasses: Map<string, ConstructorType> = new Map();
// class decorator
export function myDecorator<T extends ConstructorType>(targetConstructor: T) {
// create the modified class
const newClass = class extends targetConstructor { /* ... */ }
// register the modified class
registeredClasses.set(targetConstructor.name, newClass);
// and return it
return newClass;
}
export function doSomethingWithMyDecoratedClasses() {
//... some behavior that relies on `registeredClasses`
}
Declaration of a decorated class in file someClass.ts
import {myDecorator} from 'myDecorator.ts'
#myDecorator
class SomeClass { /* ... */ }
Making use of doSomethingWithMyDecoratedClasses in anotherFile.ts:
import { doSomethingWithMyDecoratedClasses } from 'myDecorator.ts`
//...
doSomethingWithMyDecoratedClasses()
//...
The problem is that I need to make sure that SomeClass has been added to registeredClasses before I make this call to doSomethingWithMyDecoratedClasses. And, in fact, I've written a number of such classes in my app, and I need to make sure they are all registered.
My current best understanding is that I need to call import 'someClass.ts' in anotherFile.ts (and, in fact, import all files where decorated classes are declared), so really I need to import someClass1.ts, import someClass2.ts, ...
Is that the best/only approach? Is there a recommended pattern for doing so?
Most applications have an index file that is responsible for importing the top level things. If you import doSomethingWithMyDecoratedClasses there, you'll guarantee that everything else is imported first.
An alternative would be to not call it in the root level of a module, and instead wait for an event.
I have a newbie question on TypeScript imports. I tried to make a class which holds some data in a static variable, and the data is lazily initialised in getInstance() method.
myStaticClass.ts:
class MyData {
x = 1;
}
export class MyStaticClass {
private static data: MyData;
static getInstance() {
if (MyStaticClass.data == null) {
console.log('data is null, initialising');
MyStaticClass.data = new MyData();
}
return MyStaticClass.data;
}
}
I imported this class in 2 other classes:
a.ts
import { MyStaticClass } from './MyStaticClass';
// NOTE the typo above - uppercase file name
export class A {
logX() {
console.log(MyStaticClass.getInstance().x);
}
}
index.ts
import { MyStaticClass } from './myStaticClass';
import { A } from './a';
console.log(MyStaticClass.getInstance().x);
new A().logX();
To my surprise, the output of ts-node index.ts is
data is null, initialising
1
data is null, initialising
1
If I correct the import the output is as expected - data is initialised only once.
I also checked that I get one initialisation for one variant of spelling (added 3rd class with another letter in upperCase)
Can anyone explain why this behaviour is in place?
(Additionally, what tools / debug statements I could have used to identify what is happening?)
Can I force TypeScript to flag this as error?
I am on MacOs, TS 3.6.3, node-ts 8.4.1
While on Windows two differently cased file names always point to the same file, on other platforms they do not. This means that imports with different file names are treated as different modules, this is by design and is not considered an issue (see here for node discussion)
The simple solution is to force consistent file casing to be used when importing modules. Typescript does have a compiler option to force this named forceConsistentCasingInFileNames (See docs). This option should prevent such issues.
I have created a class in Typescript that implements a simple stream (FRP). Now I want to extend it with client side functionality (streams of events). To illustrate my problem, here is some pseudo-code:
class Stream<T> {
map<U>(f: (value: T) => U): Stream<U> {
// Creates a new Stream instance that maps the values.
}
// Quite a few other functions that return new instances.
}
This class can be used both on the server and on the client. For the client side, I created a class that extends this one:
class ClientStream<T> extends Stream<T> {
watch(events: string, selector: string): Stream<Event> {
// Creates a new ClientStream instance
}
}
Now the ClientStream class knows about map but the Stream class doesn't know about watch. To circumvent this, functions call a factory method.
protected create<U>(.....): Stream<U> {
return new Stream<U>(.....)
}
The ClientStream class overrides this function to return ClientStream instances. However, the compiler complains that ClientStream.map returns a Stream, not a ClientStream. That can be 'solved' using a cast, but besides being ugly it prevents chaining.
Example code that exhibits this problem:
class Stream {
protected create(): Stream {
return new Stream()
}
map() {
return this.create()
}
}
class ClientStream extends Stream {
protected create(): ClientStream {
return new ClientStream()
}
watch() {
return this.create()
}
}
let s = new ClientStream().map().watch()
This does not compile because according to the compiler, the stream returned from map is not a ClientStream: error TS2339: Property 'watch' does not exist on type 'Stream'.
I don't really like this pattern, but I have no other solution that is more elegant. Things I've thought about:
Use composition (decorator). Not really an option given the number of methods I would have to proxy through. And I want to be able to add methods to Stream later without having to worry about ClientStream.
Mix Stream into ClientStream. More or less the same problem, ClientStream has to know the signatures of the functions that are going to be mixed in (or not? Please tell).
Merge these classes into one. This is a last resort, the watch function has no business being on the server.
Do you have a better (more elegant) solution? If you have an idea that gets closer to a more functional style, I'd be happy to hear about it. Thanks!
What you're trying to do is called F-bounded polymorphism.
In TypeScript this is done via the this keyword. Take a look at Typescript's documentation for polymorphic this types. If you follow the documentation, you should be able to implement what you want :-)
Actually, just make sure that you're returning this in your member methods and you should be fine!
Up to Geb version 0.10 the example code below has worked just fine:
package whatever
import geb.Module
import geb.Page
import geb.spock.GebSpec
class ExampleSpec extends GebSpec {
def 'MODULE - Y U NO HAVE THE RIGHT CLASS?'() {
when:
ExamplePage page = to ExamplePage
then:
verifySomething(page.theModule)
}
boolean verifySomething(ExampleModule module) {
// ...
}
}
class ExamplePage extends Page {
static content = {
theModule { module ExampleModule }
}
}
class ExampleModule extends Module {
}
I wanted upgrade to the latest 0.13.1 but apparently the breaking (regressive I would say) change has been introduced which results with:
groovy.lang.MissingMethodException: No signature of method:
geb.navigator.NonEmptyNavigator.verifySomething() is applicable for
argument types: (geb.content.TemplateDerivedPageContent) values:
[whatever.ExamplePage -> theModule: whatever.ExampleModule]
I've noticed that the same happens but with different class since version 0.11, the exception message is as follows:
groovy.lang.MissingMethodException: No signature of method:
geb.navigator.NonEmptyNavigator.verifySomething() is applicable for
argument types: (geb.content.SimplePageContent) values: [theModule -
SimplePageContent (owner: whatever.ExamplePage, args: [], value:
null)]
Why module declared with a given, specific class looses it at runtime? How to prevent that?
Objects implementing Navigator interface (which includes classes extending from Module) and returned from content definitions are wrapped with TemplateDerivedPageContent objects which delegate to the underlying object but also allow to produce a meaningful path to the object for error reporting.
The wrapping of modules worked in older versions of Geb, then it got inadvertently removed and now it's back. Even though you can still call all the methods of the module when it's wrapped thanks to TemplateDerivedPageContent dynamically delegating to the underlying object you run into trouble in cases like yours - when you want to strongly type your code that uses modules. Therefore I'm still undecided what we should sacrifice here - better error reporting or ability to strongly type and this wrapping might be removed in a future version of Geb.
Luckily there is a workaround - if you want to strongly type code that consumes modules then use a getter instead of a content definition to declare them. In your case it would be:
class ExamplePage extends Page {
ExampleModule getTheModule() {
module ExampleModule
}
}
I am in the process of porting my JS+requirejs code to typescript+requirejs.
One scenario I haven't found how to handle is circular dependencies.
Require.js returns undefined on modules that are also dependent on the current and to solve this problem you can do:
MyClass.js
define(["Modules/dataModel"], function(dataModel){
return function(){
dataModel = require("Modules/dataModel");
...
}
});
Now in typescript, I have:
MyClass.ts
import dataModel = require("Modules/dataModel");
class MyClass {
dataModel: any;
constructor(){
this.dataModel = require("Modules/dataModel"); // <- this kind of works but I lose typechecking
...
}
}
How to call require a second time and yet keep the type checking benefits of typescript? dataModel is a module { ... }
Specify the type using what you get from import i.e
import dataModelType = require("Modules/dataModel");
class MyClass {
dataModel: typeof dataModelType;