@benlesh
Nothing here yet.
Nothing here yet.
No blogs yet.
I'd love to be able to dedicate more time to making RxJS better for everyone, keeping up on PRs, updating docs, establishing better relationships with contributors, working with standards bodies and browser vendors to ensure RxJS stays in-line with upcoming changes to the web. It would be practically a full time job for more than one person. It's just hard because I don't have the time, my day job is important too, and kids gotta eat ;) haha.
A) You can use timer instead of interval to send a request right away but have the same effect: timer( 0 , 1000 ); // which is the same, basically, as: concat(timer( 0 ), interval( 1000 )) B) You'd use share or shareReplay which makes the observable multicast, thus "sharing" it's values with many subscribers. Since it's something happening on an interval, I'd use shareReplay(1) , because that is going to cache the previous value and give it to a new subscriber right away, instead of them having to wait for the next notification. timer( 0 , 100 ).pipe( switchMap( () => this .http.get(url)), shareReplay( 1 ), ) The above approach is what you'd what to do. BTW: I recommend against using IntervalObservable.create , that's more of an implementation thing from the library, instead import { interval } from 'rxjs/observable/interval'; . That will give you a static function to use.
Oh I definitely did all the same things anyone else had to do. Basically you do a phone screen. Then you come in for a day and you sit through 5-6 45 minute interviews, each of which involves whiteboarding through a problem. You're asked questions, most of which are probably way harder than they need to be, and you're expected to write and talk your way through it. Talking through your thought process, asking questions, and considering edge-cases is key. If you want to study for one, I recommend going to http://www.geeksforgeeks.org/ and trying to solve some of the problems there, then looking at the REAL answer, and trying again. Just keep practicing like that until you have most of the patterns memorized. It's sort of fun anyhow. Just remember, the person interviewing you DID NOT come up with whatever binary search or sorting algorithm you're answering with. They had to memorize it just like you. They're only as smart as you are.
SSR is something you think about to address perf issues with time-to-first-interactive. I think SSR is here to stay, but it's definitely not something that is required in all apps. Or even most apps, really. As for compilation, any templated framework (Angular, Glimmer, etc) is going to, and should have, a build-time step to compile templates into simple functions that update DOM or write HTML. That's definitely a trend I don't see stopping anytime soon.
I think React has been a huge driver for most recent innovations. Another thing you're going to start seeing more of is async functions and async function* (Async generators). Those are pretty powerful and intuitive. Finally, WASM. WASM isn't quite ready yet. But it's a dark horse. Once it's ready and there's an attractive language to use on top of it, it's going to cause some serious shake-ups in web development.
Remote work is fun but it has it's challenges. I've spent about 2 years of my career as a remote worker in the past. The upsides are obvious: No commute, can wear pajamas, you're at home, etc. The downsides are less obvious: You feel (and perhaps are) more expendable when you don't have face-time with your team. You're never "not at the office", so you feel more beholden to requests from managers at 8pm on a Saturday. You also get lonely sometimes as you don't really see other adults for a good chunk of the work day. All in all, I'd do it again for sure. It's just not all a bed of roses like people think it is.