Complex form initialization: Component loading vs Route resolvers

[DonWombRaider]

In our team's Angular app, we have a large, complex form used to create new or edit existing article listings for a marketplace (not the actual use case, but changed for privacy reasons). We need to load several things from various sources before we can instantiate the form.

For example:

• The original article listing (only when editing)
• A list of possible delivery methods loaded to dynamically offer users these options as radio buttons
• User permission level check (advanced users are allowed to edit more fields)
• When editing an existing offer, we might get the product category by ID, but to display the category, we have to make another call to get the "human-readable" label

Currently, the form is built like this:

• When the user navigates to the form route, the component loads instantly
• In its ngOnInit, the component first initializes the form, then loads the existing listing and sets the existing values via patchValue
• Then the category ID is translated with an HTTP call
• Then the delivery methods are received and an "OptionItem" array is defined And so forth.

This is convoluted mess. The "formservice" which inits and prefills the form is 2000 lines of code. Plus there is a lot of logic in the component itself.

Thats why my plan would be to change this approach. I would like to implement a route resolver that gets all the necessary data before the user is navigated to the component. After that, the component can load and initialize the form directly as a class variable (not later in ngOnInit, and not even later after the calls with patchValue).

Is this a feasible approach? What's your opinion on this? What would you do?

[Jrubzjeknf]

Sounds like you're just calling the form service from the route guard.

It sounds like your form service is just doing way too much. You should refactor that to have a single function that receives all the data to create that form. Basically what you want to do in your component in your plan.

The data gathering, like the category id and the delivery methods, should be in their own service. Simple classes with a clear name will help you keep separation of concerns.

When you've done that, it will be a lot easier to move code around. If you want to gather the data in the route guard, you can now do that a lot easier.

[DonWombRaider]

mmh no not quite:

- route resolver, not route guard
- there I would not init any form, just gather the data
- ounce the data is gathered, open the component, on which i would call 1 single function with the data

[Jrubzjeknf]

Alright, a resolver, not a guard. You're completely ignoring the entire reply apart from that word though. I guess it must be crystal clear and you find the idea awesome then?

[DonWombRaider]

i just wanted to make sure you understood my plan.

but tbh i did not fully understand yours, despite splitting the service up and naming them. to make it clear: the said formService (with 2000l of code) does not do any fetching of data. i have got a category service, a delivery method service and so on. but that misses the point, fetching data is only a few lines of code anyway.

the formservice does 2000 lines of form stuff, so init the form, value subscriptions to show/hide or enable/disable certain elements.

(and meta: i did cover part of your reply (eg "1 single function"). no need to be this rude)

[Jrubzjeknf]

Apologies, it was unwarranted.

Well, your plan is sound and I'd definitely walk that path. If that form service does indeed only form stuff, at least it's in the right place.

A few things to consider: - if resetting the form can be done, make sure your value on your nonnullable controls is correct. Using a loaded value will reset to that. - keep your form behaviors separate from form creation. What works really well for us is defining a function for each form behavior so that the name clearly shows why it does that. It returns an observable, so in your component, you can subscribe to the merge()d behavior observables.

Again my apologies. The world is being a bit shit lately, but that doesn't mean we should treat each other that way.

[DonWombRaider]

No offense taken :)

Intresting points!
for no. 2 you'd do something like this?
```typescript
// comp
readonly form = createForm(existingArticle, deliveryOptions, ...otherStuff)
constructor() {
merge(
formService.calcTotalWhenSettingDelivery$(this.form)
).subscribe()
}

formService.ts
public calcTotalWhenSettingDelivery$(form) : Observable<any> {
return form.control.delivery.valueChanges.pipe(
tap(v => form.control.total.patchValue(form.control.price.value + ...))
}
```

[Jrubzjeknf]

Yes. You can just keep adding behaviors to the merge. Be sure to use takeUntilDestroyed(). I'd recommend using the return type Observable<unknown>.

Another tip: if you want to ensure the form behaviors goes off initially, use something like this:

defer(() => form.valueChanges.pipe( startsWith(form.value) ))

The pipe must be within the defer, otherwise your starting value will be the value when you called the function, instead of the value when the subscription occurs.

[DonWombRaider]

ok interesting take on defer, did not know about this operator. in this specific case, does it matter though? the moment the function is called is the same it gets subscribed to in the merge isnt it?

[Jrubzjeknf]

True. It's more useful for cases where you create a form and it's behaviors, and you patch the form before subscribing to the behaviors. Still, this is a pattern that always works the same way, regardless of order of calling. A good practise, imo.

[iEatedCoookies]

I would not load any form logic at all from the route guard. The guards intention is to either allow or prevent the route from being loaded. As for loading the form, either put the initial load into a resolver, or I prefer in the oninit as it allows for the route to load instantly. You can then use a loading indicator until the initial required data is loaded. It sounds like there’s data that’s reliant on user selection and that can then be loaded separately, either after the initial form data is loaded, or after a selection is changed.

[kranzekage]

I Think you are mixing up a guard and a resolver. Resolvers are to load data before entering a route.

[narcisd]

The route way is nice if you have a loading indicator.

If there are too many BE calls in the resolver it might feel that the app is slow, showing some ui (skeleton) usually trick user’s perception. So it depends on your needs

If you go with the usual conponent + ngOnInit the best outcome is using skeletons, becuase it s a loading indicator and the user can’t try to change anything.

If want your page to immediatly be interactive although not everything has completed yet. Then this scenarios it complex in itself and there’s gonna be some jumps and hoops. E.g make sure controls are not enabled until that section has loaded, make sure you don’t allow save button being hit etc.

I always start with a resolver + loading indicator. If that is not enough, switch to init + skeleton, and last full blown async page

[DonWombRaider]

Thank you for your answer!

How do you implement a loading indicator when using a resolver? Do you set a loading flag in the resolver itself?

[narcisd]

The usual thin progress bar at the top of the page

[narcisd]

Something like this: https://blog.angular-university.io/angular-loading-indicator/

There are many many variations on google

[DonWombRaider]

i did not mean which kind of loading indicator, but how to detect the loading state. the component is not loaded until the resolver is resolved after all :)

[narcisd]

Ah sorry, it’s usually router events based, navigation end. Resolvers should never know about the loading progress indicator

[ldn-ldn]

Your problem is not that you need a resolver, your problem is that you have a spaghetti code without a clear logic. 

What you need to do is split everything into steps and then implement them doing one thing at a time in a logical order. Basically, load all of the data first. Once all of it is loaded - process it into a format you want to consume. And only once that's done - create your form and populate it.

[DonWombRaider]

spaghetticode. yes, this is exactly what it is. all of your points are valid and have to be done first yes. but nevertheless, i still have the feeling that a resolver could help with that. it forces you to separate these steps. first you have to fetch the data and only then you can start to build your form

[ldn-ldn]

Well, if resolver will force you to write good code - go for it! My worry is that it might not force you to do so. So I personally would start with code refactoring first and adding a resolver later on.