Santosh Yadav santoshyadavdev

  graph TD;
      A[ParentComponent]--imports-->B[ChildComponent];

My Camera Setup

Thanks for saying you like my camera set up! As you asked, here are the deets. There are cheaper ways to achieve some of the same results and possibly better ways to - however this is what I ended up with.

Pure ESM package

The package that linked you here is now pure ESM. It cannot be require()'d from CommonJS.

This means you have the following choices:

Use ESM yourself. (preferred)
Use import foo from 'foo' instead of const foo = require('foo') to import the package. You also need to put "type": "module" in your package.json and more. Follow the below guide.
If the package is used in an async context, you could use await import(…) from CommonJS instead of require(…).
Stay on the existing version of the package until you can move to ESM.

user-package-stats

I was poking around trying to figure out all the packages I have access to publish and got curious. So I write this little script to determine the download stats for all the packages I have publish access to.

Feel free to try it yourself. Just change the username passed to getUserDownloadStats.

By default, the stats are sorted by their average daily downloads (descending). That should give you an idea of the most "popular" package of a given user relative to how long that package has been around.

You can use it with npx like so:

Iterables, AsyncIterables, Observables, Oh My!

I know there is a lot of confusion around Observables, Iterables, AsyncIterables and AsyncObservables. Let's try to break this down and the reasons for each.

Pull versus Push Collections

When it comes to collections, you have two ways of thinking about collections, push versus pull. With pull, the consumer is in control of when you get the items, but with push, you get the values when the producer is ready.

Pull Based Collections

What Hiring Should Look Like

This is definitely not the first time I've written about this topic, but I haven't written formally about it in quite awhile. So I want to revisit why I think technical-position interviewing is so poorly designed, and lay out what I think would be a better process.

I'm just one guy, with a bunch of strong opinions and a bunch of flaws. So take these suggestions with a grain of salt. I'm sure there's a lot of talented, passionate folks with other thoughts, and some are probably a lot more interesting and useful than my own.

But at the same time, I hope you'll set aside the assumptions and status quo of how interviewing is always done. Just because you were hired a certain way, and even if you liked it, doesn't mean that it's a good interview process to repeat.

If you're happy with the way technical interviewing currently works at your company, fine. Just stop, don't read any further. I'm not going to spend any effort trying to convince you otherwise.

	<link rel="shortcut icon" width=32px>
	<canvas style="display: none" id="loader" width="16" height="16"></canvas>

	<script>
	class Loader {
	constructor(link, canvas) {
	this.link = link;
	this.canvas = canvas;
	this.context = canvas.getContext('2d');
	this.context.lineWidth = 2;

	import { inject, InjectionToken } from '@angular/core';

	import { LumberjackLogDriverConfig, lumberjackLogDriverConfigToken } from '@ngworker/lumberjack';

	export const myLogDriverConfigToken = new InjectionToken<LumberjackLogDriverConfig>('__MY_LOG_DRIVER_CONFIG__', {
	factory: () => inject(lumberjackLogDriverConfigToken),
	});

	import { Injectable, Inject } from '@angular/core';

	import { configToken } from './config.token';
	import { Config } from './config';

	@Injectable({
	providedIn: 'any', // 👈 Tree-shakable, only bundled if used
	})
	export class ConfigService {
	constructor(@Inject(configToken) private config: Config) {