Hi @simon0191 , thanks for the PR.

I'm not 100% sure what the use case for this feature is. It's already possible to update multiple parts of the state at once. For example this code updates both a.b and c.d:

Demo

import update from 'immutability-helper';

const state = {
  a: {
    b: 'ab',
  },
  c: {
    d: 'cd',
  }
};

const state2 = update(state, {
  a: {b: {$set: 'AB'}},
  c: {d: {$set: 'CD'}},
});

(window as any).app.innerHTML = JSON.stringify(state2, null, 2);

A couple of API points. This seems like a kitchen sink function (not a bad thing), in which case we may want to allow more flexibility. What do you think about replacing first and each with delayAllowed or timeAllowed and have it
take a number | Date | ((info: Info) => number | Date). That would also allow the more flexibility in subsequent items and can fine tune the time based on the current time, previous values, as well something like () => min(moment().add('4 seconds'), APP_DEADLINE).

Also the meta and with seem redundant and can be merged into a timeoutWith (not 100% on that name either TBH). Also I'm wondering if it makes sense for the timeoutWith to just become timeoutReason and be a string that's always wrapped in a TimeoutError, 95% of the time the user won't switch this to a plain obs value but if they didn't want it to actually throw they could just pipe directly on it

Taking your examples above it would turn into:

source$.pipe(
  timeout({
    // First item must happen by '10/22/2021, after that every 1 second
    timeAllowed: info => info.seen === 0 ? new Date('10/22/2021') : 1000
    timeoutReason: info => `Timeout out after ${info.seen} values. Reason: 'Too slow!'. Last value: ${info.lastValue}`,
  }
})
)


source$.pipe(
  timeout({ 
    // If the first value does not arrive within 4 seconds, timeout.
    // After that, values may arrive after any delay
    timeAllowed: info => info.seen === 0 ? 4000 : Infinity
  }).pipe(
    catchError(err =>
      of(`Timeout out after ${err.info.seen} values. Reason:''Too slow!''. Last value: ${error.info.lastValue}`);
    )
  ),
)

I know I kind of have the examples backwards where the first example throws and the second doesn't but I think the point still gets across.

Thoughts?

Nice!

This is amazing!! One small suggestion I had to make this more approachable for most folks (even if we're targeting "power" users: Can we include a giant snippet (or many small snippets) where we label things while giving concrete examples. I'm thinking of some code like this

import { Observable } from 'rxjs'; 

const thisIsTheObservable = new Observable(function thisIsTheProducer(thisIsTheObserver) {
  thisIsTheObserver.next('this value is being nexted');
  setTimeout(() => {
    thisIsTheObserver.complete();
  }, 1000);
  return function thisIsTheTeardown() {
    console.log('tearing down');
  }
})

const thisIsThePartialObserver = {
  next(value) { console.log('got:', value); },
  complete() { console.log('finished') }
}
const thisIsTheSubsription = thisIsTheObservable.subscribe(thisIsThePartialObserver);

const doneWithObservable = Math.random() > 0.5;

if (doneWithObservable) {
  thisIsTheSubsription.unsubscribe();
}

I'm sure some of the terms are not going to fit into this format but a large chunk will and will make those terms less esoteric.

I think the latest lint-staged does this at the end by default

OK, I think I've got it. Let me know if this is what you had in mind

I think you should go back to #5449 and look at what was there before that PR's changes. In particular, this line seems to have been changed:

const source = input ? from(input as ObservableInput<ObservedValueOf<R>>) : EMPTY;

And the assertion was removed. If that doesn't help, I can look at this tomorrow, but, IMO, the gist of it is to go back to what it was before #5449, but remove the void business.

Got it, does that mean that this is no longer a type error?:

const a = defer(() => { throw new Error(); });

We should simplify the types here to just be:

function defer<T>(callback: () => ObservableInput<T>): Observable<T>

Just getting back to this now, is looks like this causes some TS weirdness with union types

export function defer<T>(observableFactory: () => ObservableInput<T>): Observable<T> {
  return new Observable<T>(subscriber => {
    let input: ObservableInput<T>;
    try {
      input = observableFactory();
    } catch (err) {
      subscriber.error(err);
      return undefined;
    }
    const source = from(input);
    return source.subscribe(subscriber);
  });
}

defer(() => true ? of('3') : of(1)) // Type 'number' is not assignable to type 'string'

This also breaks https://github.com/ReactiveX/rxjs/blob/master/src/internal/observable/iif.ts#L99

Changing iif.ts to use ObservableInput or changing defer.ts to use SubscribableOrPromise doesn't fix the issue either.

Also this definition has the same issue as well:

export function defer<R>(observableFactory: () => ObservableInput<R>): Observable<ObservedValueOf<R>> {

I need to spend a bit more time on this to figure this out, it's possible I'm missing something obvious (and if so please point it out)

I guess I misunderstood that comment then. I tried the changes in https://github.com/ReactiveX/rxjs/blob/362d1d4fc1d7f15e7168453ea640079d0ca19dba/src/internal/observable/defer.ts#L56-L57 but that causes a slew of other errors such as

it('should error with void functions', () => {
  const a = defer(() => {}); // $ExpectError
});

And functions that return undefined should be no problem, as undefined is not a valid ObservableInput.

I thought we wanted to reject functions that don't return an observablelike value

Are the current dtslint tests incorrect? Otherwise I don't see how else we can get the expected behavior without nested conditionals.

Fixes #5511

There's no api_guardian:verify command

Done, I've updated the tests and dstlint spec to reflect the changes

We should have an autoformatter that catches things like this

Is it worth mentioning rxjs-for-await? I'm 50/50

Good catch, I'm surprised this wasn't already "here be dragons"ed already

Please fill in this template.

• [x] Use a meaningful title for the pull request. Include the name of the package modified.
• [x] Test the change in your own code. (Compile and run.)
• [x] Add or edit tests to reflect the change. (Run with npm test.)
• [x] Follow the advice from the readme.
• [x] Avoid common mistakes.
• [x] Run npm run lint package-name (or tsc if no tslint.json is present).

Select one of these and delete the others:

If adding a new definition:

• [x] The package does not already provide its own types, or cannot have its .d.ts files generated via --declaration
• [x] If this is for an NPM package, match the name. If not, do not conflict with the name of an NPM package.
• [x] Create it with dts-gen --dt, not by basing it on an existing project.
• [x] Represents shape of module/library correctly
• [x] tslint.json should be present and it shouldn't have any additional or disabling of rules. Just content as { "extends": "dtslint/dt.json" }. If for reason the some rule need to be disabled, disable it for that line using // tslint:disable-next-line [ruleName] and not for whole package so that the need for disabling can be reviewed.
• [x] tsconfig.json should have noImplicitAny, noImplicitThis, strictNullChecks, and strictFunctionTypes set to true.

Published to v3.1.1

The use of invariant pulls in loose-envify which in turn pulls in js-tokens. This has little consequence when used with React since it already uses them, but when used outside React these are relatively heavy dependencies (as already noted in #126)

Also as noted in https://github.com/kolodny/immutability-helper/issues/83#issuecomment-401852092, this way of writing invariant checks can cause significant performance penalty, since the error message arguments are always evaluated (unless combined with a compile-time code rewriter, but this project doesn't do that)

I would like to suggest at a minimum switching to use tiny-invariant, which is compatible with invariant except that it does not provide the %s formatting. The library still works with compile-time code rewriters and does not have any dependencies (and is tiny itself).

And better would be to also run the code through a transformer as part of the build process so that the built code only evaluates error arguments if the condition fails (or see my suggested improvement to tiny-invariant https://github.com/alexreardon/tiny-invariant/issues/62 if a build-time transformation is not desirable).

Also updates TS to the current latest to ensure we're not doing anything incorrect with types

closes #156 /cc @davidje13

Great work, thanks!

The MapSpec type was unnecessarily strict about the what could be allowed in $set commands.

Resolves #161

Version: 3.0.2 Typescript: 3.7.5

The example code in this comment (shown below) does not compile in typescript.

var state = new Map([
    ['mapKey', { banana: 'yellow', apple: ['red'], blueberry: 'purple', obj: {a:true} }]
]);

var updatedState = update(state, {
    ['mapKey']: {
        apple: { $set: ['green', 'red'] },
        obj: {$toggle: ['a']}
    }
});

tsc error:

Type '{ apple: { $set: string[]; }; obj: { $toggle: string[]; }; }' is not assignable to type '{ $set: { banana: string; apple: string[]; blueberry: string; obj: { a: boolean; }; }; }'.
  Object literal may only specify known properties, and 'apple' does not exist in type '{ $set: { banana: string; apple: string[]; blueberry: string; obj: { a: boolean; }; }; }'

Since the object is a literal the error is kind of verbose, but the tl;dr is that typescript thinks the $set command can only accept a value of the same type as the Map's value type, and not additional commands operating on the current value in the map.

Running the sample code in a plain JS environment (or presumably by forcing update to use any as the spec type) produces the expected result, so I think this is strictly a problem with the exported typescript types.

It's also possible typescript is inferring a type weirdly, but I'm not sure what I would need to change to make it work correctly.

I've done some work independently, not realizing this PR existed. I have a couple of the tricky cases worked out. The types are pretty well tested and are quite robust. Feel free to incorporate anything from that branch to this PR.

https://github.com/kolodny/DefinitelyTyped/commit/7bae6984215fbe1ac784959cffbd44008cb8fa94#diff-536a520cf5eea35920533711cf917823

Whoops. I searched for recoil before creating this PR, not sure how I missed that

Please fill in this template.

• [x] Use a meaningful title for the pull request. Include the name of the package modified.
• [x] Test the change in your own code. (Compile and run.)
• [x] Add or edit tests to reflect the change. (Run with npm test.)
• [x] Follow the advice from the readme.
• [x] Avoid common mistakes.
• [x] Run npm run lint package-name (or tsc if no tslint.json is present).

Select one of these and delete the others:

If adding a new definition:

• [x] The package does not already provide its own types, or cannot have its .d.ts files generated via --declaration
• [x] If this is for an NPM package, match the name. If not, do not conflict with the name of an NPM package.
• [x] Create it with dts-gen --dt, not by basing it on an existing project.
• [x] Represents shape of module/library correctly
• [x] tslint.json should be present and it shouldn't have any additional or disabling of rules. Just content as { "extends": "dtslint/dt.json" }. If for reason the some rule need to be disabled, disable it for that line using // tslint:disable-next-line [ruleName] and not for whole package so that the need for disabling can be reviewed.
• [x] tsconfig.json should have noImplicitAny, noImplicitThis, strictNullChecks, and strictFunctionTypes set to true.

pluck('prop') is a shorthand for map(x => x.prop), the main advantage to using pluck was the path traversal safety, meaning you can do

pluck('foo', 'bar', 'baz')

and this would be fine even if the emitted value didn't have a foo property. Contrast this with
map(x => x.foo.bar.baz) which will error if the emitted value doesn't have a foo property

With optional chaining this advantage is no longer true since you can now do

map(x => x?.foo?.bar?.baz)

And it will be as safe as the pluck usage. Note that having proper TypeScript typing for pluck is quite complex and not as robust as the map usage which is a major reason to prefer the map method

Added

fixes #5446

I'd be open for a PR

should:

update(collection, {2...

be

update(collection, {[2]...

here, in the readme:

Nested collections

const collection = [1, 2, {a: [12, 17, 15]}];
const newCollection = update(collection, {2: {a: {$splice: [[1, 1, 13, 14]]}}});
// => [1, 2, {a: [12, 13, 14, 15]}]

?

Either usage works, not really a typo. Open to a PR if it bothers you but closing this issue in the meantime

Is it possible to simply create a copy without any changes? I tried: const deepObjectCopy = update(defaultValue, {}); but with no luck

Hmm, so the selectors can't have an async element to them in that case. Is there any way around that? This means that if I wanted to have if/else logic in the selector, I can't make the function async before that selection. Is there some way to get both async and conditional deps?

https://codesandbox.io/s/recoil-counter-demo-9uir6?file=/src/App.js

Comment out the setTimeout line and it works fine

A couple of notes here. I couldn't figure out how to test this since it doesn't work in oldish versions of TS like 2.8 which is where the dtslint tests run. If there was some way to enable/disable for TS versions that would be one solution.

Note that in the example in #5439 you need to test key === true in order to get the type checking to work for both the if and else blocks. This may be related to https://github.com/Microsoft/TypeScript/issues/26852

Another item and this is probably a TS issue is that while all 4 of the following usages work, the 5th one, using an inline type guard with no explicit arg type, doesn't work. I'm guessing there's some TS weirdness going on that's probably a bug but I can't explain what is making it behave that way

function isNumberFromAny(input: any): input is number {
  return typeof input === 'number';
}

function isNumberFromStringOrNumber(input: string | number): input is number {
  return typeof input === 'number';
}

// Works!
of('a', 1, 'b', 2).pipe(
  groupBy((x: any): x is number => typeof x === 'number'),
  mergeMap(group => {
    if (group.key === true) {
        group.subscribe(x => x.toExponential(1)); // x is number here
    } else {
        group.subscribe(x => x.toLowerCase()); // x is string here
    }
    return group;
  })
);

// Works!
of('a', 1, 'b', 2).pipe(
  groupBy((x: string | number): x is number => typeof x === 'number'),
  mergeMap(group => {
    if (group.key === true) {
        group.subscribe(x => x.toExponential(1)); // x is number here
    } else {
        group.subscribe(x => x.toLowerCase()); // x is string here
    }
    return group;
  })
);

// Works!
of('a', 1, 'b', 2).pipe(
  groupBy(isNumberFromAny),
  mergeMap(group => {
    if (group.key === true) {
        group.subscribe(x => x.toExponential(1)); // x is number here
    } else {
        group.subscribe(x => x.toLowerCase()); // x is string here
    }
    return group;
  })
);


// Works!
of('a', 1, 'b', 2).pipe(
  groupBy(isNumberFromStringOrNumber),
  mergeMap(group => {
    if (group.key === true) {
        group.subscribe(x => x.toExponential(1)); // x is number here
    } else {
        group.subscribe(x => x.toLowerCase()); // x is string here
    }
    return group;
  })
);

// THIS IS BUSTED!
of('a', 1, 'b', 2).pipe(
  groupBy((x): x is number => typeof x === 'number'),
  mergeMap(group => {
    if (group.key === true) {
        // group is GroupedObservable<true, string | number>
        group.subscribe(x => x.toExponential(1))
    } else {
        // group is GroupedObservable<false, never>
        group.subscribe(x => x.toLowerCase())
    }
    return group;
  })
);

Note that if you supply an overload that handles all those cases it works as expected:

class Service {
    setValue(value: string, option?: undefined): void;
    setValue(value: string, option: string): void;
    setValue(value: string, option?: string): void
    setValue(value: string, option?: string): void { /* some implementation*/ }
}

const service = new Service();

expect(service.setValue).toHaveBeenCalledWith('v');

So this library attempts to reuse objects as much as possible, it will only create a shallow copy when needed due to a mutation.

var update = require("immutability-helper");

const state = {foo: 1, nested1: {a: 2}, nested2: {b: 3} };
const state2 = update(state, {nested1: {a: {$set: 4}}})

console.log('state2 nested1 same?', state.nested1 === state2.nested1); // false
console.log('state2 nested2 same?', state.nested2 === state2.nested2); // true

const state3 = update(state, {foo: {$set: 5}});

console.log('state3 nested1 same?', state.nested1 === state3.nested1); // true
console.log('state3 nested2 same?', state.nested2 === state3.nested2); // true