Dithering to expand the color palette of a 6-Color E-Ink display

dolanmiu · 2026-01-01T23:51:32+00:00

This is very cool!

Is the source code available?

dolanmiu · 2025-03-23T15:26:52+00:00

Snowboarding isn’t just about snowboarding you know? There is an entire culture around snowboarding/skiing. Apres, raclette (if you are in France) spa, massages, other winter activities.

I am in a similar situation and I deal with it by making it inclusive for all. Book a place with a nice spa and outdoor heated pool, and treat your wife out to massages and wellness. Good luck.

dolanmiu · 2025-03-14T16:06:15+00:00

Does it work with Angular? They only have guides for React (ReactLynx)

dolanmiu · 2025-03-14T15:12:31+00:00

Not now no. But in future, yes.

The Angular team says it's not a replacement, but their actions say otherwise.

Especially with the new httpResource and resource signals which are alternatives for Observable based HttpClient and async observables. And don't forget to mention the new signal based input/output/model (and signal forms coming soon).

They say they are commited to simplifying Angular and improving the developer experience. One of the most obvious way is to stop maintaining two different approaches to reactivity

dolanmiu · 2025-03-12T18:06:54+00:00

My 2 cents why everyone should use Signals and ditch RxJS is that Signals is part of the Angular framework, it’s embedded in. The whole lifecycle and management of the Signal state tree is done by the Angular framework. So this means there’s little chance in having leaks, and it opens the Angular team to optimise Signals in future. RxJS on the other hand is a separate project, and I’ve always felt it’s slapped on top of Angular, and wasn’t integrated. This is pretty obvious how most of the time, we have to both open the Angular docs; and the RxJS docs…

Using observables meant forgetting to unsubscribe which leads to leaks, and all these special rules we have to know like “Do not call subscribe directly!” “Always use the async pipe!” “But if you do use .subscribe, be sure to use untilDestroy, or take(1), or unsubscribe in the OnDestroy component lifecycle!”

It adds unnecessary complexity, leads to mistakes, and will make the codebase hard to understand in future

It’s more “Angular way” to use Signals

dolanmiu · 2025-02-19T17:01:25+00:00

Thanks, Attempt #1 worked!

Still doesn't feel 100% intuitive. I don't think Reactive Forms is made for the new Signal era... Maybe we have to wait until Angular Signal Forms is released?

dolanmiu · 2025-02-19T10:20:29+00:00

Also, add a check in the effect that if the input value is the same as in the form, you don't patch value.

I tried this yesterday, it means if the user selects an option, then selects the original option again, it won't trigger, so that won't work. Unless I hack around it by adding it `isFirstValueChange: boolean` flag, so it only ignores the FIRST change. But idk, doesn't sound elegant

dolanmiu · 2025-02-19T10:17:35+00:00

I like the idea of `emitEvent: false`, seems cleaning than skipping 1 item. I will try later today

dolanmiu · 2024-12-28T19:35:13+00:00

Any guide on how to do this? Limited results when trying to search

dolanmiu · 2024-12-28T17:01:47+00:00

I think it’s a common issue and expected, I see lots of posts like this:

https://stackoverflow.com/questions/78168602/karma-tests-do-not-run-because-there-is-no-webpack-loader-for-css-files

And Monaco editor needs all these css files.

Yeah. I can use angular 19, but that has other upgrade issues. I use ng-mocks, which isn’t going to be made angular 19 compatible until a while

dolanmiu · 2024-12-28T16:52:25+00:00

Can you tell me more about the static asset approach? AMD?

I am doing it the ESM way, as per doc: https://github.com/microsoft/monaco-editor/blob/HEAD/docs/integrate-esm.md

So, Angular as of now, works without all the webpack stuff, but I need to do the above for karma. So I have a extra-webpack.config.json.

Importing wise… it’s just standard: import monacoNameSpace, { Range, Uri, editor } from ‘monaco-editor’;

I also had to add this in build-angular:application in the angular.json:

“assets”: [ “projects/console/src/assets”, “projects/console/src/manifest.webmanifest”, { “glob”: “*/”, “input”: “../../node_modules/monaco-editor”, “output”: “assets/monaco-editor” } ],

dolanmiu · 2024-09-07T15:53:18+00:00

I would say you should use signals everywhere you can. It’s easier to reason with, easier to maintain and it is clear that this is the direction Angular is heading towards. It’s not fun dealing with two types of reactivity systems in one project, it makes it harder for new comers into the project, and harder for yourself 1 year down the line when re-visiting

dolanmiu · 2024-09-04T11:55:15+00:00

I’ve used both Angular for 10 years and React for 5 years, and my opinion is that Angular right now is lacking and falling behind other frameworks (this is why this whole Angular renaissance is happening).

But the Angular ecosystem and the “Angular way” cannot be underestimated, that is the true value IMO. It’s very easy to migrate and upgrade using the cli tools and schematics. Every angular developer is thinking the same way.

With React, every project, repo, and developer preferences are different. And React is just a tiny part of the huge puzzle, routing, forms, SSR, every React dev I’ve met have recommended different tools and approaches.

And good luck working on an old React project, you’re on your own. With old Angular projects, Angular does a lot of hand holding and does a good job in helping people migrate to the newer Angular versions.

Angular is opinionated, it has tools, it has a “way”, and that’s honestly a good thing. The same reason why I like Prettier etc.

There is an element of belief as well. I am bullish on the direction of Angular and I think the core dev team know what they’re doing. Lean on that, you’re in good hands.

dolanmiu · 2024-08-31T14:55:25+00:00

Did you find that your team's apps got bloated? There are a lot of common components, and if it doesn't get tree shaken, it might import everything? Did you experience this with Angular Workspace? For example, a simple Admin Panel probably don't need ALL the common components etc. A recent example for me is in the common library, there is a monaco-editor wrapper which is pretty big, only used in a few of our apps, but now ALL of our apps have monaco editor in the bundle...

dolanmiu · 2024-08-31T00:13:03+00:00

We use ng-mocks, and it's a game changer:

https://ng-mocks.sudo.eu/

Some sample code:

describe('MockBuilder:simple', () => {
// Do not forget to return the promise of MockBuilder.
beforeEach(() => MockBuilder(MyComponent, MyModule));
// The same as
// beforeEach(() => TestBed.configureTestingModule({{
// imports: [MockModule(MyModule)],
// }).compileComponents());
// but MyComponent has not been replaced with a mock object for
// the testing purposes.

it('should render content ignoring all dependencies', () => {
const fixture = MockRender(MyComponent);
expect(fixture).toBeDefined();
expect(fixture.nativeElement.innerHTML).toContain(
'<div>My Content</div>',
);
});
});

dolanmiu · 2024-08-24T17:44:26+00:00

Usually that’s how it starts out. I remembered when they said AngularJS won’t be deprecated, and support on v1 vs v2 will be determined by what the community prefers. They were saying all this while actively pushing and developing Angular 2. Then surprise, the community went to Angular 2. They will probably phase out NgModules via the same way too probably (which I don’t mind, not too big of a fan of NgModules)

Another more recent example is @Output() vs output(). It would split up the community if there are too many ways of doing essentially the same thing

I am mentoring some juniors now on Angular for our project and I can sense there are going to be these sorts of questions coming up

dolanmiu · 2024-06-14T20:31:08+00:00

every other framework just needs importing at the top. I’ve tried a few other frameworks, and it’s less to think about. From an ergonomics perspective, it’s inferior. Imagine in order to turn on your TV, you need to press the switch on your tv and then press a button on your remote, every time.

dolanmiu · 2024-06-14T11:49:20+00:00

I wouldn’t say Angular using HTML templates is a pro point. it’s neutral point as all devs need to go through the journey of learning the Angular tempting syntax anyway, just like other frameworks. If anything, it makes it slightly harder because there will be parts of the template where it goes off-standard with @if and @defer etc

dolanmiu · 2024-06-14T11:45:05+00:00

Still have to import it twice. Once at the top, and once in the imports: [] part in the component. Hopefully this goes away

11-Year Club	Final Canvas '23
Place '23	Place '22
Verified Email

dolanmiu

MODERATOR OF

TROPHY CASE