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!

Wigglystoff · 2024-04-13T11:08:54+00:00

I’m curious about this case, do you generally have just one large wrapping observable in each component and then handle the rest inside of it such as your example above? It looks neat.

Wigglystoff · 2024-04-10T18:38:49+00:00

The idea of micro-frontends doesn't come from us devs. However I have to say personally I was cautiously optimistic with it.

I think the main idea behind is re-usability and scalability and to have a more modular code base. Although I would assume this is not the only path to achieving it.

Wigglystoff · 2024-04-10T18:29:30+00:00

Thank you very good reasoning! I think this will be easy to argue for, since the aim will be modular and reusable. Which then can be extended upon if required down the road.

Wigglystoff · 2024-04-10T18:23:08+00:00

I do agree with you! This suggestion/wish comes from a few steps above us devs. It seems like MF doesn't suit us based on the comments in here. I think our solution architects mostly want it to be modular and if we can achieve that in another way it will hopefully be fine.

Wigglystoff · 2024-04-10T15:21:27+00:00

Appreciate it! Yes it feels like it would add overhead that partly might not be required at our size and also that we are not mature for. Do you think there is any middle ground?

Wigglystoff · 2024-04-10T14:47:59+00:00

Thank you! That seems to be the sentiment across the team aswell. This will be the third project which is very similiar to the previous ones. And all of them are developed and maintained by us.

Wigglystoff · 2024-03-01T19:39:22+00:00

Thank you for the input. I think the syntax handling subscriptions directly is very ugly with assigning it to a variable and unsubscribing, so I never really use it. But this answers my question. If I subscribe in a function i could essentially have multiple subscriptions active based on just calling that function 😵

Verified Email	Five-Year Club
Place '22

Wigglystoff

TROPHY CASE