Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Tamir Dresher
    @tamirdresher
    Hi
    Cédric Menzi
    @cmenzi
    I've just strumbled over your book. Which is very nice.
    Tamir Dresher
    @tamirdresher
    Thank you :-)
    Cédric Menzi
    @cmenzi
    I also like your async + RX part....
    Tamir Dresher
    @tamirdresher
    I'm glad you liked it
    Cédric Menzi
    @cmenzi
    But I've currently have a problem and don't know how to solve it properly
    Tamir Dresher
    @tamirdresher
    Sure
    Cédric Menzi
    @cmenzi
    May you can shorty check this out:
    http://stackoverflow.com/q/40761107/2537999
    Tamir Dresher
    @tamirdresher
    I'd be happy to help
    Cédric Menzi
    @cmenzi
    I think there is currently no proper solution
    Tamir Dresher
    @tamirdresher
    Not sure i follow. Do you wish to block the test until all the observable is complete?
    Cédric Menzi
    @cmenzi
    exactly
    without custom TaskScheduler so that I can use Task.Run and without sychronization properties like WaitHandles, etc
    You did it always with WaitHandles in the tests but I don't want to make production code dirty just for that
    Tamir Dresher
    @tamirdresher
    You can use Concat instead of SelectMany and Wait on the observable. It will work but thats a non reactive solution
    Yiu can also await an observable
    Cédric Menzi
    @cmenzi
    The thing is that all this cool stuff works perfect in production code but not in testing
    Tamir Dresher
    @tamirdresher
    You must make the test determenistic by awaiting the final result
    Unit test shouldnt involve threading
    Cédric Menzi
    @cmenzi
    Yes that's true. But when the SUT contains a Task.Run I'm lost
    Tamir Dresher
    @tamirdresher
    Instead of creating a task you should have used the scheduler
    And inject it
    In production use the NewTaskScheduler
    Cédric Menzi
    @cmenzi
    Aha.
    Tamir Dresher
    @tamirdresher
    In the test use the TestScheduler
    Cédric Menzi
    @cmenzi
    Yes, I always do that
    Or Immediate
    So the thing is again: Do not mix TPL and RX
    I also found this. But it's feels also strange:
    Tamir Dresher
    @tamirdresher
    Not exactly. Make it so that the concurrency you introduce is testable and/or mocked
    Cédric Menzi
    @cmenzi
    Yes, It always works when the tasks are already completed
    UnitTest is solveable but not IntegrationTests like Testing with SpecFlow
    Tamir Dresher
    @tamirdresher
    The problem exist in any kind of test that involve threads or tasks
    In thise places you must wait on some trigger
    Cédric Menzi
    @cmenzi
    Yeah, we tried it with NotifyPropertyChange or CollectionChanged
    Then it also works
    Ok. UnitTest -> use Mocks, IntegrationTests -> Use Triggers
    That sounds plausible.
    Thank you very much for chatting... And again..Thx for writing this cool book
    :-)
    Tamir Dresher
    @tamirdresher
    :+1: thank you
    Cédric Menzi
    @cmenzi
    have a nice evening...Or day don't know where you live
    bye
    :clap:
    Jakob Ferdinand Wegenschimmel
    @JakobFerdinand

    Hello Tamir,

    First of all thank´s for the great book!

    I´m trying to integrate Rx more and more in our application. Therefor I start to build some framework components internally with Rx.
    There´s often the case that I receive a value as a method parameter and I just want to push that value into a stream of values.

    class Component
    {
        public IObservable<string> Values { get; }
    
        public void AddNewValue(string value)
        {
            // push the value to into the Values stream
        }
    }

    My solution to that is always to use a Subject<T> like that:

    class Component
    {
        private readonly Subject<string> values = new Subject<string>();
        public IObservable<string> Values => values;
    
        public void AddNewValue(string value)
        {
            values.OnNext(value);
        }
    }

    But I´m not sure if that is good solution. On introtorx they write it´s always better to create observables with the Observables.Create<T>() methods.

    The Create factory method is the preferred way to implement custom observable sequences. The usage of subjects should largely remain in the realms of samples and testing.

    So is there a better way or is it valid to use Subject in that cases?

    Tamir Dresher
    @tamirdresher
    Hi @JakobFerdinand, thank you very much fir the
    For the kind words
    For the case you're describing, Subject sounds like the best option. It's just a question of whether your design for accepting values and pushing them to the stream is the right one.
    Jakob Ferdinand Wegenschimmel
    @JakobFerdinand

    When you build an application entirely with Rx that would probably not be a good design.
    But here I have a long existing project that is still under active development and I can´t change everything at once.
    So it´s a place to start.

    In the real application I´m building a view to display all currently running Tasks.
    So for example there´s code like that:

    Task.Run(() => DoHardWork()).Observe();

    where Observe() is an extension method which was represented in my upper example by AddNewValue().
    So in my view I subscribed to the IObservable<Task> to display them in in a list and at the same moment i transform the Task object into an IObservable to remove it from the list when it completes.