after the reminder about typing earlier, will add one more item to the discussion - as of the last push there is some very PoC code that generates a typescript definition file as part of the "cased" build: https://github.com/unexpectedjs/unexpected/blob/spike/camelCasedProxy/Makefile#L45
partial extract of the generated file:
export = casepected;
declare const casepected: casepected.Expect;
declare namespace casepected {
/**
* The `expect` function is used every time you want to test a value.
* You will rarely call `expect` by itself.
*/
interface Expect {
/**
* The `expect` function is used every time you want to test a value.
* You will rarely call `expect` by itself.
*
* @param actual The value to apply matchers against.
*/
<T = any>(actual: T): Matchers;
it: Matchers;
}
interface Constructable {
new (...args: any[]): any;
}
type Result = Promise<any[]> | undefined;
interface Matchers {
notToBeOk(value: string): Result
notToBeTruthy(value: string): Result
toBeOk(value: string): Result
toBeTruthy(value: string): Result
notToBe(value: string|any): Result
toBe(value: string|any): Result
@alexjeffburke if we keep types out of the picture as it is basically impossible to type a meta programming system. (You can still make a your cased unexpected capable of writing out a type definition dynamically with all the plugins you chose to add, and any custom assertions to a file if you want).
Couldn't we just use a real https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy object instead of precalculating the methods?
@sunesimonsen there were a couple of reasons that may not qualify as good - first to make sure it works down to IE11 like the rest of Unexpected. Second, I have a riff on the build time stuff that encodes the functions within the library so you’d actually see a
toEqual() definition in the source and the string assertion it translates to
Especially if that allows for a much less intrusive implementation?
ohhh you mean in terms of where it would run right? I guess it comes down to what we want from it really, there’s no reason it shouldn’t run there, more an impl decision. I’m also not sure it’s really
yeah exactly - I don't think we have many new users that care about running tests in IE11 or earlier (this is a gut feeling-thing - I don't suppose we have a lot of data around it) - so why don't we start with an implementation that takes a few shortcuts with regards to compatibility but also allows us to keep it as a side-car to core? We can always promote it, if it proves to be hugely successful and all the users demand it
I think the main priority when doing experiments like this is to keep the existing bits isolated from effects and fall out, until we know for sure that it is going to survive.
Wouldn't you be able to implement unexpectedCamel as a separate module if that wrapped core, if you used the proxy as @sunesimonsen suggested?
@/all in summary: I believe the experiment has proven what it set out to - modulo some minor things we seem well placed to do this now if we wanted to. The bigger questions seem to be:
- is this a problem Unexpected should take on?
- are we ok with exposing two APIs to our ‘native’ assertions?
- is a second interface something that lives in or out -side of core if we are comfortable with it?
There’s likely some discussions and agreement we need on an approach as a group. Do folks agree on a GitHub issue as a next step?
If you want to be serious, you could have separate docs and not mention unexpected :-)
@alexjeffburke how are you dealing with chained assertions?
Because a native proxy solution would really know when to end the assertion chain.
expect(() => {
camelCased(['foo', 'it', 'do']).toHaveAnItemSatisfying(
camelCased.it.toHaveLength(3)
);
}, 'not to throw');
That seems like a fair trade-off.
I think we'd be in dicey waters if we have to start worrying about the all the possible combinations
that's actually one thing that a proxy might have over an 'encoded' version, but glad it feels ok
where you're chaining the result
expect(queriedForFirst(foo, '.foo')).toSatisfy(<div>wat</div>)
@alexjeffburke by the way, now I remember the utility of Yggdrasil experiment. Having that structure would enable you to know when you need to stop your call chain. But given that I haven't really finished it over the years, it is probably a sign that it will never be done.
You need to stop when you hit a shift and wait for the result, but something like that.
It works in my mind :-S
the for normal assertions where it isn't allowed:
