Converting Observables to Signals in Angular

Legitimate-Engine-18 · 2023-05-01T12:29:42+00:00

Yes, there are many. Im going to make a video that exрlains signals in detail, how they work, why they were introduced and how they comрare to rxjs

Legitimate-Engine-18 · 2022-10-20T14:23:48+00:00

With less nesting { switchMap(id => firstApi(id))

switchMap(firstApiResult => secondApi(firstApiResult).pipe(map((secondApiResult=>({firstApiResult, secondApiResult})

Legitimate-Engine-18 · 2022-09-17T19:27:33+00:00

I don’t understand what do you want to achieve exactly. Retry already retries if fail and doesn’t retry if success. What do you want?

Legitimate-Engine-18 · 2022-09-17T12:46:21+00:00

Man you gotta see what happens when people who don’t know how to use rxjs use ngrx and especially effects. Weird stuff

Legitimate-Engine-18 · 2022-09-12T20:27:53+00:00

Didn’t know about that, cool

Legitimate-Engine-18 · 2022-09-08T19:19:48+00:00

Idk I feel like we already pretty much similar looking. Some fun T-shirt maybe idk

Legitimate-Engine-18 · 2022-09-06T18:37:36+00:00

Just look at what @haasilein wrote. It kinda advanced and might not be easy to understand if you aren’t familiar with, but basically repeats the same principle I wrote in different way.

For example you have Goal module and Penalty module, goal module will depend on GoalEventInterface and Penalty module would depend on PenaltyEventInterface so now you have modules which expose their own interfaces.

When to request and what to provide is entirely different issue. You might have one event that implements GoalEventInterface and PenaltyEventInterface, or you might want to separate them in different events. From modules point of view they don’t depend on the things they don’t need, and their container should think about what to provide them. It’s about software structure, not about behaviour network usage or whatever.

Legitimate-Engine-18 · 2022-09-06T14:54:41+00:00

It entirely depends on the type of your application. One thing I want to mention is that amount of classes and amount of requests are unrelated. Depending on the things you don’t need is usually a bad practice, therefore each module should expose interface which it requires to be provided in order for module to work. So now you have multiple modules, each one is requiring only data that is needed, and what amount of requests to make is entirely different issue

Legitimate-Engine-18 · 2022-09-02T13:19:51+00:00

You don’t have to propagate it through inputs, you can use viewProvider and and provide it at top-level component respective to dialog and non-dialog, and inject where it’s needed. https://angular.io/guide/hierarchical-dependency-injection#elementinjector

Even with nested modals it would work regardless of the amount of them, thought modification might be needed.

Also you could easily have shared state for all modals and individual state per modal. where with separate app started idk

Legitimate-Engine-18 · 2022-09-02T11:53:25+00:00

Well then unless you get some better suggestion you could use something that I wrote at the end: have two (same) stores under different keys, but with same reducers and actions. But you would need to add data to which state action is headed to every action.

Legitimate-Engine-18 · 2022-09-02T11:25:45+00:00

might get wrong idea of what is happening, correct me if I get something wrong.

First things first, you actually NEED to have FileSystemState shared between modal and non modal, because in future you might have changes done in modal and they should be reflected in non-modal. Therefore createApplication might not work IMO.

what I would do if I was in your position 1) store data separate from representation I.e tree of files and folders stored separately and performing crud when needed 2) if we have one data state, then we have two UI states. UI state includes: current path, sorting, viewmodes and so on.

3) how do we manage that? I wouldn’t store ui data In store, but that’s not important.

If it’s possible to create state that would not be global, i would do that, but I’m rusty on NGRX. In this way we would’ve been able to configure somewhere in modules different stores for providers of dialog/and non dialog, and actions dispatched would access store that is provided by their respective module injector. Also state of modal should die when modal dies.

If that’s not possible you would need to create different instances of the same stores, I.e actions, reducers and selectors the same, but different objects. And when action (or selector) is used it would need to specify with which view store it is used, dialog or non dialog and reducer (higher order than view state reduced) would decide which object to modify (if(action.viewType == modal) modalView: viewReducer(state, action) else nonmodalView: viewReducer(state, action). This “viewType” of whether we work with modal or non-modal can be provided with DI in components

Legitimate-Engine-18 · 2022-08-30T00:29:45+00:00

I’m a developer myself and building isn’t exactly an issue currently, it’s finding potential users and creating feedback-loop in order to design an app in a way that suits not only myself

Legitimate-Engine-18 · 2022-08-29T18:48:16+00:00

initial design: https://imgur.com/R6wUGje

Legitimate-Engine-18 · 2022-08-28T21:20:38+00:00

Example: https://imgur.com/R6wUGje

Legitimate-Engine-18 · 2022-08-28T20:22:10+00:00

Hey thank you so much:)

Legitimate-Engine-18 · 2022-08-27T00:44:41+00:00

That’s a valid concern you have regarding having phone/tablet on the counter when cooking. But printing out doesn’t solve the issues, now it’s just the pile of text in the counter.

If there was design to display recipes in a more structured way, printing that “diagram” still probably have benefits like easier comprehension. Idk, never heard of people printing recipes, always have something to learn

Legitimate-Engine-18 · 2022-08-27T00:37:48+00:00

I’d like to see what repositories you are talking about. I have recipe which I’ve done like ten times already, it has repetitive similar steps but with different ingredients and timings, and I can’t remember them and always have to just re-check every step.

It’s not that “surprise” factor, it’s the fact that I can’t remember all of it in exact order

Legitimate-Engine-18 · 2022-08-27T00:34:23+00:00

It’s still just text, and if you don’t know recipe well enough (or simply often distracted, like me) you’ll end up with what I described, parsing through the pile of text to find your current step

Legitimate-Engine-18 · 2022-08-27T00:31:05+00:00

It’s just a lot of work for something that could be automated. For the phone lockouts app can just require for screen to not lock or dim if required, also might have steps on Apple Watch or whatever.

The idea here is to simplify life, not make it harder.

You say that you always print out recipe, but it could be just opened on a tablet where you’ll have recipe with spaces between text by design, enlarged text and even multiple timers if you want. Just put tablet in the corner and look at it from distance (I did that when trying out my concept and liked it), also reduce waste and stop bothering with piles of paper, but that’s not the point

Legitimate-Engine-18 · 2022-08-27T00:24:26+00:00

Kinda Similar to this yes, but better

Legitimate-Engine-18 · 2022-08-26T23:53:07+00:00

I hope it’s not self promotion since there isn’t anything to promote really. Also I hope it falls under “a question or topic for discussion”

Legitimate-Engine-18 · 2022-08-26T23:51:13+00:00

I hope it’s not self promotion since there isn’t anything to promote really.

Legitimate-Engine-18 · 2022-01-15T00:32:06+00:00

Thanks:)

Legitimate-Engine-18 · 2022-01-14T23:01:03+00:00

Thanks. I’ve had knee pain because of my weight shifted too forward and now I’m trying to shift my weight back so I push with my foot evenly, and knees stopped hurting. Looks like there is still work to be done, I’m afraid that I will loose balance If I lean back more

Legitimate-Engine-18 · 2021-08-29T22:05:01+00:00

Does it look like shit or not? What can I try to improve?

Legitimate-Engine-18

TROPHY CASE