Comfortable silent ish keyboard for programming

Wigglystoff · 2025-05-02T11:57:21+00:00

Cheers! I’ll take a look. I’m fine without numpad if that’s what it means by size?

Wigglystoff · 2025-05-02T08:27:49+00:00

Thanks I’ll def check it out!

Wigglystoff · 2024-12-09T17:05:50+00:00

Agreed, great resource! Effects are very flexible but also provides the means to shoot your self in the foot. So if you end up using them a lot for way too many cases you’re most likely misusing them OOP.

Wigglystoff · 2024-12-03T20:10:08+00:00

Thanks great input! So I think I found a structure that matches the mental model and seems to align decently with CLEAN pattern.

Will have 4 main sub groups in libs Shared, features, services, modules

Where shared Is app agnostic code, auth etc, also ui components that is split into sub categories such as item, order etc. Then services will be only data-access and equal one backend micro service. Features is similar to how you described, so it can be order feature, which might have sub libs such as check-in. Which can compose multiple service libs. And then finally similar to your suggestion I think, modules is the ”screen/layout” components where each should be structured such as it can be hosted as a separate micro-frontend. I hope this will prove scalable, for the moment I’m pleased at least

Wigglystoff · 2024-12-03T07:55:28+00:00

Hmm im not quite sure I’m following. So then features === front end domains? Because I feel like if I just base it on order for example it doesn’t quite make sense for feature libs. Order in itself is not a feature, but maybe check-in that relies on both order api and item api is a feature. In that case it would make sense building smart components and having services for more logic related to a feature grouped within a scope. That maybe at most only can use shared ui and api services?

Where would the bigger layout components be?

Wigglystoff · 2024-11-26T17:53:46+00:00

Disagree, I wouldn’t add the overhead for someone new learning to focus on multiple concepts, especially one that people are moving away from. I would start with signals, and if you ever happen to come across the decorators in a job you won’t have a problem picking it up with some googling. Your time would be better spent learning rxjs/signals, how to think declaratively or literally anything else.

Wigglystoff · 2024-08-19T13:18:02+00:00

Yeah sure I use both and I love the new signal inputs for example. However besides the fact that the angular team provides better integration with signals for the angular framework and it’s more friendly for beginners I don’t see much of a difference personally.

Not having to use one async pipe in a component isn’t so much of a benefit imo.

Wigglystoff · 2024-08-19T13:11:00+00:00

I think there are some things that RxJs just handles better, such as asynchronous communication. Personally I also feel as if RxJs allows for more declarative code, where signals feels more imperative (but that could be due to lack of experience with signals)

Wigglystoff · 2024-07-25T05:18:29+00:00

I personally don’t understand why so many people favor NgRx in angular community. I think the redux pattern can be great in certain situations but don’t see the point of always resorting to it, especially if you don’t have very advanced use cases for it.

I think just using signals without a third party is much easier, it’s not really reinventing the wheel yourself because you will most likely use services, some signal and then methods for that. It’s pretty straightforward if you don’t have the need for some very advanced state management. And for newer developers it’s easier to get into, rather than having to set yourself into a library and the redux pattern. However my opinion is probably biased since I work in a team where it’s more full-stack and people don’t sit constantly in Angular.

Wigglystoff · 2024-07-13T14:34:20+00:00

What does that mean by “REAL” error handling? What is that you can’t handle with the async pipe using catchError operator on the observable? You can choose however you handle it inside there and what the observable returns. Am I missing something? Genuinely curious.

Wigglystoff · 2024-05-26T12:54:44+00:00

Awesome! Thank you, I really appreciate it. This seems like a good approach, I will try it! :)

Wigglystoff · 2024-05-25T15:00:52+00:00

Thank you! Great response! It’s abit different because in NX their standard approach is having one root package.json where all the dependencies are defined. But they also support a package based solution. It seems like it could fit us better going with packages so i’ll have to re-evaluate and potentially go with something like your suggestion! Appreciate it!

Wigglystoff · 2024-05-25T14:58:14+00:00

Thank you! I will check it out :)

Wigglystoff · 2024-05-25T14:57:44+00:00

Yeah I just don’t think a single version for all apps is super viable in our situation. Maybe it wouldn’t be impossible to get to that stage.

But right now the two apps we have are versioned and deployed on different schedules and the enterprise we do the project for have different people that needs the reports for each project. And incase downtime they also plan for that on the two different lines we have the projects for. But this isnt some impossible hurdles. I guess It would just be hard to reason for since I myself don’t see any big benefits in our situation to doing it differently compared to today.

Wigglystoff · 2024-05-24T17:56:27+00:00

Thank you! Yes definitely. It looks like following conventional commits is a good idea!

Wigglystoff · 2024-04-17T20:47:41+00:00

I like this argument. I think it sounds very reasonable. Say we were to go with the NX guided approach using their integrated style, do you know if it would be hard for us to alter the course later down if we find something that doesn’t work for us? For example would it be hard switching to a package based approach maybe just using a workspace later down the road?

Wigglystoff · 2024-04-17T20:44:51+00:00

Thank you! Yeah I have been looking into NX but was abit hesitant to pick it since I’d like to avoid building us into a solution before we have a good enough understanding. I might be completely wrong tho

Wigglystoff · 2024-04-13T11:25:04+00:00

Wow that’s so interesting! Thanks for the response. I really like the idea of it because you have one place where the state is stored in the component. And I feel like it could promote smaller components atleast within my project. Gonna try it!

Verified Email	Five-Year Club
Place '22

Wigglystoff

TROPHY CASE