Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 05 22:33

    alexjeffburke on camelCasedProxy

    Split the camelCased chunk into… Prepare the camel cased interna… Throw together some code that g… (compare)

  • Dec 05 10:52

    alexjeffburke on camelCaseProxy

    Throw a basic camel case proxy … Exclude the "non-empty" variant… Split binding from the function… and 5 more (compare)

  • Dec 02 22:09
    joelmukuthu commented #668
  • Dec 02 21:50
    papandreou commented #668
  • Dec 02 21:41
    joelmukuthu commented #668
  • Dec 02 21:22

    joelmukuthu on addAssertion

    (compare)

  • Dec 02 21:22

    joelmukuthu on master

    docs(addAssertion): document al… (compare)

  • Dec 02 21:22
    joelmukuthu closed #668
  • Dec 02 21:04
    joelmukuthu commented #668
  • Dec 02 21:02
    joelmukuthu synchronize #668
  • Dec 02 21:02

    joelmukuthu on addAssertion

    docs(addAssertion): simplify al… (compare)

  • Dec 01 11:34
    joelmukuthu review_requested #668
  • Dec 01 11:34
    joelmukuthu review_requested #668
  • Dec 01 11:34
    joelmukuthu review_requested #668
  • Dec 01 11:33
    joelmukuthu synchronize #668
  • Dec 01 11:33

    joelmukuthu on addAssertion

    docs(addAssertion): fix typos docs(addAssertion): match headi… (compare)

  • Dec 01 11:26
    joelmukuthu synchronize #668
  • Dec 01 11:26

    joelmukuthu on addAssertion

    docs(addAssertion): inline hand… (compare)

  • Nov 26 20:42
    joelmukuthu commented #668
  • Nov 26 20:42
    joelmukuthu commented #668
Alex J Burke
@alexjeffburke
oh, actually dom example would need to be camelCased.plugins.dom(<subject>).toHaveACallSatisfying(<value>)
Alex J Burke
@alexjeffburke
are we keen enough to do something in this space that its worth opening an issue so we can document all the experiments and thoughts around a direction like this so far?
Alex J Burke
@alexjeffburke
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
Sune Simonsen
@sunesimonsen

@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?

Alex J Burke
@alexjeffburke
@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
Gustav Nikolaj
@gustavnikolaj
Wouldn't it be fair to say that the "camelCase"-facade has less compatibility than core?
Especially if that allows for a much less intrusive implementation?
Alex J Burke
@alexjeffburke
@gustavnikolaj I’m not completely sure I follow - could you clarify less compatibility? :)
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
Gustav Nikolaj
@gustavnikolaj
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?
Alex J Burke
@alexjeffburke
@gustavnikolaj yeah - in this case though there are additional concerns within the group around doing so given this exposes native assertions which I think are very valid, especially if we want to communicate this as a real alternative to some of the alternatives

@/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?

Alex J Burke
@alexjeffburke
Btw, I should clarify that I’m very willing to attempt a simple Proxy based version as something we could release on the side, but I’m unsure doing so would address all the concerns. Let me try it though!
Sune Simonsen
@sunesimonsen
@alexjeffburke I would like it to exists as a separate module if there is no reason for it to be in core.
If you want to be serious, you could have separate docs and not mention unexpected :-)
Gert Sønderby
@gertsonderby
<pulls curtain aside> "Haha! It was Unexpected all along!!!"
Alex J Burke
@alexjeffburke
@sunesimonsen I’ll try to head in that direction :)
Sune Simonsen
@sunesimonsen
@alexjeffburke by the way, it is not because I don't think it is a cool idea, that I don't want it to start in core. I think it is great.
@alexjeffburke how are you dealing with chained assertions?
Because a native proxy solution would really know when to end the assertion chain.
Alex J Burke
@alexjeffburke
@sunesimonsen I set up bound versions of the assertions on a .it. object, so at the moment the following is in the test suite:
      expect(() => {
        camelCased(['foo', 'it', 'do']).toHaveAnItemSatisfying(
          camelCased.it.toHaveLength(3)
        );
      }, 'not to throw');
Sune Simonsen
@sunesimonsen
so no expect(foo).toHaveItemsSatisfyingToHaveLength(3) right.
That seems like a fair trade-off.
Alex J Burke
@alexjeffburke
@sunesimonsen no, I stayed away from that
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
Sune Simonsen
@sunesimonsen
You will need to figure out what to do with things like this
expect(foo).whenMounted().queriedForFirst('.foo').toSatisfy(<div>wat</div>)
Alex J Burke
@alexjeffburke
riiiight
where you're chaining the result
Sune Simonsen
@sunesimonsen
I have seen things like this, that makes sense:
expect(queriedForFirst(foo, '.foo')).toSatisfy(<div>wat</div>)
Alex J Burke
@alexjeffburke
that's actually quite neat - the way my experiment works right now, it'd probably end up being:
Alex J Burke
@alexjeffburke
expect(expect.it.queriedForFirst(foo, '.foo')).toSatisfy(<div>wat</div>)
Sune Simonsen
@sunesimonsen
@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.
Alex J Burke
@alexjeffburke
ahhhh that makes sense - I guess it woukld be something like you can navigate down a tree of assertions 'up-front' and you naturally get to the last edge you can follow?
Sune Simonsen
@sunesimonsen
yes
You need to stop when you hit a shift and wait for the result, but something like that.
It works in my mind :-S
Alex J Burke
@alexjeffburke
I've done something a little naughty to disallow using expect.it type assertions on the RHS if they aren't supported:
the for normal assertions where it isn't allowed:
Alex J Burke
@alexjeffburke
@sunesimonsen I think I found another little thing we might want to clean up - "to be ok" takes an optional message on the RHS and pass it into expect.fail() a la assert
Andreas Lind
@papandreou
to be ok should just die, it doesn’t make any sense.
Sune Simonsen
@sunesimonsen
👍