Store: Suppressed thrown Error should no be supressed

[odahcam]

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
}

[splincode]

could you provide an advanced example with a repository or something that would help us find an error

[odahcam]

Yes, next week.

[RuiAlias]

Hi, I agree with @odahcam. Here's a little demo https://stackblitz.com/edit/ngxs-simple-wuhvmv.

There's a mistake in that code that would've been easily detected by seeing a TypeError.

I actually found a bug like this one in my code (by inserting a console.log(ex) on that catch -- and for this reason I will keep it there). https://github.com/ngxs/store/blob/0d3210c5259aeeac368803c61d05ff5af86fb662/packages/store/src/utils/selector-utils.ts#L56-L61
(Opinion: By suppressing TypeError you are kinda changing the semantics of the language. It's weird...)

[splincode]

PR please

[odahcam]

Ninjas, I've forgotten to create the example, thanks for following up.

[arturovt]

Closing this as inactive.

[odahcam]

What? This needs to be solved...

[splincode]

[arturovt]

@odahcam Install the latest dev version, we're gonna publish 3.5.0 in some days.

[arturovt]

Yeah, gonna reopen that and will close after 3.5.0

[odahcam]

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.

[splincode]

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

[RuiAlias]

I agree with @odahcam.

@splincode I didn't understand your last comment. Did you mean that the plan is to change the default to be "no error suppression" by version 4?

(Relevant PRs: #1015 and #1087)

[splincode]

@RuiAlias https://github.com/ngxs/store/issues/827

[arturovt]

@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

[splincode]

Released in 3.5.0