store: Suppressed thrown Error should no be supressed

I don’t know why, but my states seems to have all turned into immutable states (that’s nice btw), but this change brought to me a LOT of data management errors where one of them was REALLY annoying. Take a look at the following lines of code retrived from NGXS production code:

// 1601-1312 "...\node_modules\@ngxs\store\fesm5\ngxs-store.js"

        // if the lambda tries to access a something on the
        // state that doesn't exist, it will throw a TypeError.
        // since this is quite usual behaviour, we simply return undefined if so.
        try {
            return memoizedFn.apply(void 0, __spread(results));
        }
        catch (ex) {
            if (ex instanceof TypeError) {
                return undefined;
            }
            throw ex;
        }

What’s the problem with them you ask, the answer is a short story: they suppress any attribution to read-only state properties Error that should be thrown. This happened to all my selectors, where I had lots of Array.maps and other stuff and it took me hours to find out what was going on with my application, because that Error that would make me understand WTH was going on was being suppressed and never came to my logs (uou that was a lot of 'was’s).

Sorry for the poorly written issue, it happends that I lost too much time and I’m force to do things like running now. Thanks in advance!

Versions and stuff:

// Windows 10 x64
// Chrome Canary x64
// VSCode with a terrible bloated of bugs debugger
// packages:
{
    "@angular/core": "^7.1.4",
    "@ngxs/devtools-plugin": "^3.2.0",
    "@ngxs/logger-plugin": "^3.2.0",
    "@ngxs/storage-plugin": "^3.2.0",
    "@ngxs/store": "^3.2.0", // 3.3.4 installed
}

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 16 (10 by maintainers)

Most upvoted comments

@RuiAlias

The first feature we’re working on is the ability to NOT provide state class as the first argument of any selector.

Also we’re strictly thinking about the backward compatibility for our users. Currently all our work is centralized across providing the migration guide to the NGXS 4.x, that will be published some time.

E.g. see @SelectorOptions

sorry, but then it will be a critical change, this flag will be changed in the ngxs version 4

I think this shouldn’t be suppressed by default and have the option to enable suppression. That’s just my opinion btw. Thanks for solving.

Yeah, gonna reopen that and will close after 3.5.0

What? This needs to be solved…