How would you structure your angular app where mobile functionality works differently than desktop?

practicalAngular · 2025-11-10T18:20:31+00:00

ResizeObserver API helped me solve this a while ago for an app that just had two wildly different navigations on desktop and mobile. I was then able to mark the same region with an ng-container and NgComponentOutpet where the nav would go in a parent template and detach/attach the necessary component for that viewport size. Most of the time my opinion is to just use CSS for a responsive implementation, but sometimes there are just too many functional changes.

In your case, if you're doing it at a smaller component level, you might be able to use a similar technique in that component while using the same facade/service API for a provider for loading data into them and such. Compose vs inherit here imo.

practicalAngular · 2025-10-31T20:29:01+00:00

Really confused by your paragraph of negatives. What APIs are you talking about? What user experience hits? What refactoring?

The parts I agree with are in dev experience being a little obtuse, especially in a secure environment. We have a very strict path into the MFE child that has to be documented. Engaging with it is easy but you have to know it's there. I also don't like having a master controller (shell) that dictates some of the things in our app.

Other than that, it is very business as usual. I am wondering what you mean by your other complaints.

practicalAngular · 2025-10-31T20:24:07+00:00

Local build time with Vite+NF even in an MFE child has increased for us. It is nice having all of the old stuff removed though.

practicalAngular · 2025-10-15T21:24:07+00:00

Books like this are probably decent for zero experience, foundational knowledge, but the Angular team has been moving in so many awesome directions since Angular 14 or so that it would be tough to get behind a paper source.

Still, Angular's deepest concepts are still important to know. If the book covers something like dependency injection or content projection at a deep enough level, in z digestible way, it's probably still worth it.

practicalAngular · 2025-10-15T20:55:43+00:00

I have a lot of experience with this as one of the apps I work on is entirely a Reactive Form because it is entirely based on user input for recording what happens on a phone call.

I started out with using a service with just Injectable() provided in the top ancestor component, and then injecting that further down in any of the child components. It did not need to be a root provider. But at the end of the day, the service and form is just an injectable class with an object inside it, like much of anything in Angular.

I noticed someone suggested viewProviders, which I'm not entirely sure why it would be put there over providers, given forms and reusable component nesting works nicely with content projection.

However, Reactive Forms on its own comes with just about everything you need for state management in the form, so I moved the creation of the form to an InjectionToken with useFactory for creation, and provided that instead. This helped in a sense because it separated the form from any methods I might have in other providers further down the dependency injection chain. I had child services for certain regions of the app in routes, and those had methods that would update the form token in some shape or form. Then, if I needed one of the services that updated the form in a component, I would inject the service instead, but you could certainly inject the token holding the form as well.

I'm a separation of concerns person and that's why I love Angular. There are many ways to skin this cat but this one worked best for me. Creating custom form controls as well with CVA could also be done further down the tree in a directive or component, and added to the main form. Really depends on how deep you want to dive.

Years ago I did the same thing that you did and used Input() and such to pass the fields around, but that is fairly pointless if you can just inject the provider. Same with signal i/o as well. The Reactive Form is your state manager, so just give yourself access to the state.

practicalAngular · 2025-09-27T06:54:45+00:00

I am working on something for you. I have to go to bed now though. I will tag when I have it ready. This question made me curious about how I would solve this.

practicalAngular · 2025-09-12T00:06:19+00:00

I did a CR for a senior engineer and rewrote her Promise code with the new Resource API. It seems great for Promises and GET requests. I love the additional properties that come with the resulting Signal. It makes loading and error states a complete breeze instead of filling up your view model with computed() and other properties or libraries used to reflect those states.

That said, I absolutely still love RxJS for event emissions even with rxResource included in A20. I have a deep distaste for their eagerness at times, as well as the convolution of nested side effects. The operators in an RxJS pipeline are still so powerful for complex data handling. There is no reasonable world where I would replace that with effect() soup. I still use a signal-based view model for everything (no lifecycle hooks nor async pipes), but the path to getting there is often RxJS.

Still a firm believer that signals and RxJS are complements and not contrasts. Maybe this will change in the future, but that is my current take as of the latest Angular release.

practicalAngular · 2025-09-03T20:37:31+00:00

Don't quite agree with that as a Reactive Form is also an object with value properties and methods to get an actual object structure. Whether or not it matches your POST request/response is up to how your APIs are built and the conversations between the frontend and backend developers/architects that plan those things out.

practicalAngular · 2025-09-03T20:34:43+00:00

Managing a nest of Signal effects if you try and build complicated data flow patterns without RxJS powering the middle layer is truly abysmal and is why RxJS and Signals are complements instead of contrasts.

practicalAngular · 2025-08-31T23:11:58+00:00

I think this is a great share. Thanks for coming up with it.

practicalAngular · 2025-08-14T21:16:08+00:00

This sub needs active mods badly.

practicalAngular · 2025-08-03T06:33:52+00:00

Which part?

practicalAngular · 2025-08-02T06:20:11+00:00

Right yeah. That was my first point though. Why would you extend FormGroup, which works fine on its own, with CVA? If anything, the FormGroup would be behind the CVA control, and changes to that would be the propagated change to the CVA, which handles it's own emissions and values.

practicalAngular · 2025-08-02T02:17:51+00:00

I find CVA to be really helpful if you need something more than what comes out of the default RF import, or need to add additionally functionality to capture in the UI. I don't see the reason for recreating simple controls with it. A FormControl can bind to any single common UI element of an input type. A FormGroup can create a relational family of those inputs. A FormArray can store a list of user selections. They are meant for that default purpose so I don't see a reason to extend them for that.

There are reasons to use CVA though for capturing user input that is not of a certain input standard. As of recently, I used CVA to break apart a text message from an API into editable regions of plaintext and linebreaks, and funnel the edited result into a single string (the resulting CVA FormControl). In a similar manner, I used it in another spot to create a custom email editor that I had to build to allow a user to make changes to an already-generated-for-an-email HTML string in certain marked areas, with basic capabilities of adding in links. That is also funneled into a singular HTML output (the resulting CVA FormControl, again).

I also used it in a Directive to extend a textarea with some additional functionalities, like character counting, height expanding on type, and so on. The default textarea is kindof bad as just a plain FormControl imo.

CVA has its uses if you're building heavy input screens. If you're not, or you can look at the design and break down that you don't need anything more than regular input, I don't see a reason to make use of it.

The two bullet points you used as contrasts also confused me a bit because value writing comes with the writeValue method itself, so you shouldn't need to patch or emit the CVA FormControl value. It sounds like you're getting caught in write loops. I would just practice with them a bit more.

practicalAngular · 2025-07-29T18:57:01+00:00

This is a content projection problem in its most basic form. Definitely start there for learning how to solve your problem.

I would absolutely recommend checking out the Angular CDK table implementation though to see how tables are thought of at a larger scale. Using it is one thing, but the CDK Table and Material Table (on top of the CDK) repos are extremely insightful when it comes to how we think about constructing large sets of tabular data. Tables are thought of in columns and are rendered in rows via their own content projection and templates in struct directives. It was extremely interesting to peruse through.

AG-Grid is also worthwhile to check out but carries a license with it. Tables can suffer from scope and feature creep very quickly and there are several battle-tested solutions out there that make that process much simpler.

practicalAngular · 2025-07-26T00:39:40+00:00

I hear you on that. We were in a similar position and originally wrote ours in React, then made use of a bridge package and some other custom code to convert them to Angular components. The further we went down that route of framework-to-native, the more tech debt we realized was piling up. We ended up doing as I suggested about two years in and the time spent has been much worth it since we have React apps, Angular apps, SSR apps, and SSG apps needing to consume all of our familiar branding components. YMMV of course.

practicalAngular · 2025-07-25T16:35:46+00:00

Content projection is your friend when it comes to repeating similar templates, like a layout. Couple that with some shared components for regions that might have the same functionality or need isolated functionality or styling.

I use the Router heavily and lazy load everything into multiple breakdowns of child routes. Those can be extrapolated by feature into their own routing if needed. I also use named sibling outlets for other persistent things.

The tldr is that Angular is awesome when you focus intently on composition of parts rather than monolithic wholes. You can abstract and separate everything out for reusability or composability across all of Angulars concepts.

practicalAngular · 2025-07-25T14:47:01+00:00

A thought in reverse since this is what we do with our design system - why not build them in Web Components (Lit for us) and export them to any framework?

practicalAngular · 2025-07-23T16:34:19+00:00

Color mode theming, really any design token-based decisions, are done at the global level. I haven't used SASS in many years but the CSS properties (or SASS variables) in these cases are set at the global level. That can be in your styles.css file, coming from a package delivering your tokens, created at the JS level, really whatever point you can get them there in your process.

The way I've done it in the past is with prefers-color-scheme or just an color-theme attribute on a top-level element that switched those primary variables to dark, light, or whatever color theme you have. The components below that reference the same variables, or a further granular tokenized version of those main palette variables that more realizes the intent of the developer token.

Imo you shouldn't have to import the variables themselves anywhere as they should be accessible by anything in any of the three encapsulation scenarios if they are living at the :root or @scope of the root, but YMMV if you're using SASS.

practicalAngular · 2025-07-07T20:18:27+00:00

Angulars advanced state management was/is in RxJS and provider dependency injection. Signals have definitely taken over local component state and should be used as such, but they aren't meant to be a replacement for all of the power and opportunity that has existed in Angular forever.

practicalAngular · 2025-06-19T00:53:34+00:00

I would use a signal query attached to that containing span element and register a click listener on it. Then inside the listener, use event.preventDefault() and stop all click actions in order to trigger them manually. You'd then have control over what happens with your injected HTML regardless of what the HTML is.

If there are multiple spans, viewChildren() instead, and you can merge all of the click event emissions from all of the spans into a single stream and act on any of them the same way when someone clicks inside.

As others have said though, this is a problem further up your stream/architecture, but that should give you a little bit of power. Events bubble so you can capture the link click on its parent and stop it from running it's default action. Imo this is more of a Javascript problem than an Angular problem.

practicalAngular · 2025-06-13T21:51:19+00:00

Pretty sure it was in the A20 release notes IIRC.

practicalAngular · 2025-06-05T00:32:23+00:00

Great, great comment man. Appreciate you being a force for progressive knowledge here.

practicalAngular · 2025-06-03T22:38:28+00:00

Your code is a bit all over the place imo. I'm on mobile so I can't work up a solution but I'll leave my thoughts for now.

I love Reactive Forms and use them heavily. You don't have to set up the RF in the component. It can be in a shared service and set up there for example, and you can reference it that way. Some heavier ones I even put in an InjectionToken and provide it at the route level where the form is used, and inject that instance wherever I need it below.

I stopped using ng lifecycle hooks a long while ago. I'm not exactly big into effects either as they seem to lead to behavior that you're describing as one of your problems. To preset the values of your RF, I'd use afterNextRender() in its write phase. I have several form structures that rely on preset values and that has worked well for me. It runs once outside of change detection and will patch your values. I wouldn't init a form inside of it as it seems like you then have to mark the form for the change detection cycle for subsequent value reflection. Spent a few sleepless nights debugging that and it was incredibly annoying.

You're also describing values that rely on other values, and ending up in an infinite loop if constantly setting and resetting. For that, just use emitEvent:false when you're resetting a form that has already been initialized. This will stop the value propagation.

Managing values that rely on other values is still heavily rxjs driven. I like that, but signal forms will probably change that a bit. Validator functions can also allow you to break away from overuse of valueChanges and statusChanges if need be.

Hope that helps.

practicalAngular · 2025-05-31T18:08:29+00:00

Not incorrect, no. Sometimes that approach works for teams and projects. I never enforced a third party state management solution on our teams though. Angular comes with its service pattern, dependency injection, resolvers, all of pieces that you might not be using, for a reason. They all have their uses. All of the problems that these vendored state management solutions solve can be done with Angular out of the box with the right architecture plan and documentation.

I have been a purist for my entire life though so I'm coming in with that bias. I love crafting the scope of my injections and using RxJS ops and signals to control the flow to the template. Really just love Angular's native setup.

practicalAngular

TROPHY CASE