SwiftUI Series 06｜SwiftUI component splitting and code maintainability

When the topic of “disassembling components” comes up, the first reaction is:

• This View is too long
• Split it into several sub-Views

This is certainly a start, but if the splitting criterion is just “too many lines of code”, it’s easy to end up with another kind of confusion:

• There are indeed more files
• But the status relationship is harder to understand
• Component names are becoming more and more abstract
• Pass a bunch of parameters between father and son

In other words, the page is not clearer, it just changes from one large file to many broken files.

So the truly effective component splitting is:

Make structure boundaries, state boundaries and reuse boundaries clearer at the same time.

1. First distinguish: are you dismantling the structure or reusing it?

It is common for the two things to get mixed up.

1. Split for structural readability

The purpose is to make the current page hierarchy clearer. This type of split is completely reasonable even if it is used only once on a page.

2. Split for cross-page reuse

The goal is to extract reusable components. This type of split requires more stable boundaries and more restrained interfaces.

If these two types of purposes are not distinguished, the most common consequences are:

• Obviously I just wanted to make the page clearer, but ended up prematurely extracting it as a “universal component”
• Or this pattern has been repeated many times, but it is still regarded as a partial sub-view

Therefore, the first step in component splitting is to determine what type of problem is being solved.

2. The reason why many pages become more and more messy is because View assumes too many roles.

Once a page takes on these things at the same time, it is easy to expand rapidly:

• layout structure
• Local UI state -Business status mapping
• Data formatting
• Interactive action assembly

At this time, you will find that the long code is not the root cause. The real problem is:

• What logic belongs to View
• What logic should be outside
• Which local structures deserve independent expression

The real value of component splitting is to force this boundary judgment to be made again.

3. The most worth removing first is usually “the piece with the most complete semantics on the current page”

A common situation is that as soon as the components are disassembled, they rush to find the most versatile part. But in real development, a more stable approach is often to first dismantle those pieces that are semantically complete in the current page.

For example:

• Data header area
• Article summary card
• Set item row
• Empty blocks

The benefits of these structures are:

• They are originally an independent unit in the page
• The structural semantics will be clearer after being removed
• Even if you don’t reuse it for a while, you won’t lose money

This is much more stable than trying to pump out a “super universal Cell Container” from the beginning.

4. Once the components are removed, the interface becomes a real design issue

One of the greatest values of component splitting is that it forces you to think about interfaces.

You will soon find out:

• Should this subcomponent take the original model or the formatted display data?
• It needs to know how to jump after clicking, or only expose one action
• Should it have local state, or be driven by a parent layer

If you don’t want to understand these issues clearly, the component can easily become:

• A lot of parameters
• Unclear business semantics
• The parent layer needs to know everything

So component splitting is an interface design job.

5. A very common bad smell: mixing “partial structure splitting” and “business logic splitting” together

For example, if a list card is removed, it will also be responsible for:

• Layout display
• Data formatting
• bury the point
• Business judgment after click

Although this component is independent, its responsibilities are still mixed.

A more stable approach is usually:

• Display components should focus on display as much as possible
• Keep business decisions at higher levels as much as possible
• Subcomponents expose necessary events without directly swallowing the entire business process

Otherwise, the more components are dismantled, the more fragmented the logic will be, but the complexity will not decrease.

6. When should you not rush to smoke “general components”?

This is the point where many SwiftUI projects can easily be over-designed.

If a pattern currently appears only once on a page, and:

• Business structure is not yet stable
• UI details are still changing rapidly
• I’m not sure about the boundaries yet

At this time, it is more appropriate to split it into local sub-Views within the page instead of immediately upgrading it to a general component.

Because “premature reuse” often brings one consequence:

• Component interface becomes very wide
• In order to be compatible with possible future scenarios, many options are included first

The result is that it is more difficult to maintain than not dismantling it.

7. A practical judgment: If this substructure is taken out alone, can others tell what it is?

This is a very common way for me to judge.

If a certain substructure is taken out, everyone can naturally say:

• This is a user profile header
• This is a settings row
• This is an article summary card

Then it is usually suitable for disassembly.

If you take it out, you can only say:

• This is a “combination container”
• This is a “Content Block View”
• This is a “multi-scene card case”

That most likely means that its semantics are not stable enough, and the time for splitting may not have come yet.

8. Conclusion: What is really pursued by component splitting is to have clearer boundaries.

To put it in shorter form, I would say:

The truly effective standard for splitting SwiftUI components is that after the split, the structure boundaries, state boundaries, and interface boundaries are clearer than before.

Only in this way, the components will become lighter as they are disassembled; otherwise, it will easily become more files and the system will be more difficult to read.