-
Notifications
You must be signed in to change notification settings - Fork 141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve TS Support #239
Improve TS Support #239
Conversation
@sgtoj I've started the review, this may be more productive if I sent you a PR to fix some of the grammar stuff, which will also give me a chance run the code and look at how things are fitting together. I'm getting ready for a conference talk for tomorrow. So expect to hear from me again sometime Saturday! |
@sgtoj @searls not sure if my testing methodology is correct here, but i'm running into an error. I tried to execute Here's the error message that gets thrown when
I then attempted to dig into the I'm still getting oriented with the code base. Some help and direction would be appreciated. |
@duluca (DoubledObject<Subject> = Subject) === (DoubledObject<T> = T) |
@duluca I would prefer to use |
@sgtoj Ah I see, naming generics other than T is usually then when you limit what types can be used by the generic. If you can use any object, T or TObject makes sense. If say, the object must implement an interface called IDocument, then calling it TDocument helps the user understand what's expected. So here I'd recommend going with T or TSubject. However having an ISubject defined would be helpful, if you expect the object to have specific shape. But I also don't get what |
@sgtoj So here |
Although I normally see single-letter -- T, K, V, etc -- type parameter names, I am open to the idea of using I just looked where the letters originated. Apparently, this convention is adopted from Java and C#. |
I'm not a Typescript user, but I agree that generic types should use single-letter placeholders like The real tricky bit that I would want to accomplish from a type awareness for td.js is for any created test double to have its type inferred or specified such that a compilation failure is triggered until the type is created. Same goes with creating a stubbing which then fails compilation and requires the method be written. To express this with code, what I want is for it to support a workflow like I would have in Java + Mockito. Here's how that would normally flow public void testInvoices() {
// 1. Write the fake you want
LoadsPayments loadsPayments = mock(LoadsPayments.class)
// 2. get compiler feedback that you need to go define LoadsPayments (e.g. hit ctrl-1 to quick-fix create the type
// 3. Write a stubbing of the method you want the fake to define
Payment payment = new Payment()
when(loadsPayments.load(new Date())).thenReturn([payment])
// 4. get compiler feedback that `LoadsPayments` needs an instance method `load` with parameters `(Date)` and return type `Array<Payment>`, prompting me to go create that in a way that my tools can auto-generate for me
// … rest of test goes here
} This sort of paint-by-numbers approach where writing a single isolated test informs the tooling with what it needs to create all the files/classes for you is a fantastic productivity win, and one that encourages lots of small custom types. How possible is this going to be with TypeScript? |
Yeah I saw, that was a great change. And I have more C# experience than I care to admit. Given the same guy invented C# and TypeScript, I think it's fair to carry over the conventions. And naming generics start with a capital T (i.e. TSubject or TString) is similar to how you name interfaces with a capital I (i.e. ISubject). K and V are stand-ins for Key and Value. Personally I prefer TKey and TValue. |
@searls I know that we can do that easily if we rewrite portions of the app in TypeScript, not sure if it can be achieved through type definitions alone. But then the library can be compiled down to JavaScript and continue to used without any notion of TypeScript by consumers, if they choose to. Or we could write a wrapper. |
I am entirely okay with this
… On May 12, 2017, at 11:14 AM, Doguhan Uluca ***@***.***> wrote:
@searls I know that we can do that easily if we rewrite portions of the app in TypeScript, not sure if it can be achieved through type definitions alone. But then the library can be compiled down to JavaScript and continue to used without any notion of TypeScript by consumers, if they choose to.
―
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
I am also interested on that project too. May do some work towards it weekend. |
@sgtoj @searls I've noticed that
@sgtoj let me know if you need help |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to implement test script, which will execute the code
Fix the test code so ln 58: td.replace({}, "prop"); doesn't error out
index.d.ts
Outdated
@@ -94,6 +100,16 @@ export function explain<T>(f: TestDouble<T>): Explanation; | |||
// fake: constructors | |||
// ---------------------------------------------------------------------------- | |||
|
|||
/** | |||
* Create a fake object constructor the given class. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think for is missing before the given class
export function object<T>(object: string): DoubledObject<T>; | ||
|
||
/** | ||
* Create a fake object that is deep copy of the given object. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a deep copy
@duluca Sorry... I will review and fix tonight or this weekend. So far, I have already these TS definitions for 2 different work projects; with 2 more in the works. I haven't found any issues yet. |
In |
@sgtoj I fixed up test.ts in #260, also updated package.json to actually execute the code. So once the PR can be merged, it'd be great to update this PR from master, so there's a valid CI run against this change. TODO: |
Ping that #260 is merged -- should this be revisited? |
@sgtoj do you need help with this? |
I have merged from |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
test.ts was intentionally moved under the regression folder
- Keeps it out of the src folder to prevent accidental distribution
- The CI server compiles and executes the ts code in JavaScript to ensure correct functionality
By moving code from regression to src, you're by-passing CI. Thus making this an invalid PR. Please move test code back in to the regression file.
That makes sense. I was very confused too. I will fix. |
@duluca please advise if you would like to merge and what version segment is appropriate to bump |
@searls It makes sense to me as a patch increment. |
See #238 for more information.