4
ostream
35d

Angular being crap episode 129831:

I have this error in my test. No idea where to start looking.

Comments
  • 3
    Is there more to this error measage?
    Look for possible causes of runtime errors such as array accesses and stuff
  • 3
    JS testrunners are a pain in the ass to debug but are in 90% of the cases not to blame. So without any context, I'd assume you have something wrong in your code like @Ranchu suggests.
  • 2
    What's wrong is that Angular and Angular Material documentation are a pain in my ass yeah.

    Apparently one have to provide

    ```

    providers: [{ provide: HAMMER_GESTURE_CONFIG, useClass: GestureConfig }],

    ```

    Thank you stackoverflow. Still no idea why it works though.
  • 1
    You have legacy problems, gestureconfig was deprecated and the source using it wasn't updated to v9 gesture support. You have components consuming hammerjs events indirectly via material, and they lack the configuration to understand them.

    They literally wrote an upgrade schematic to autofix this and published it in the release notes:

    https://github.com/angular/...

    "Case 2: The deprecated Angular Material GestureConfig is used in combination with a custom HAMMER_GESTURE_CONFIG. This case is ambiguous because the migration is unable to detect whether a given HammerJS event binding corresponds to the custom gesture config, or to the deprecated Angular Material gesture config. If such a warning has been reported, check if you can remove the references to the deprecated GestureConfig, or if you need to update your existing, custom gesture config to handle the events provided by the deprecated Angular Material GestureConfig."
  • 0
    @SortOfTested See? That's the kind of constants gotchas I'm talking about. The tooling is terrible.

    Should I remind you WHO's behind Angular Material and handling this dependency tree? How hard is it to insure backward compatibility (or simply to write a line of code to warn the developer).
Add Comment