[WIP] docs: discourage the Widgets layer#933
Open
Gaic4o wants to merge 2 commits into
Open
Conversation
built with Refined Cloudflare Pages Action⚡ Cloudflare Pages Deployment
|
Gaic4o
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Background
This PR updates the FSD documentation to remove the Widgets layer from the set of layers recommended by default.
After discussions with the FSD Core team, we decided that new projects should no longer be encouraged to actively adopt the Widgets layer. This does not mean that the Widgets layer is being removed or prohibited. Existing projects that already use Widgets without significant issues do not need to change their structure. The layer can still be retained when it fits the needs of the project.
The Widgets layer was originally intended for independent UI blocks that compose multiple entities and features. In real frontend applications, however, UI blocks rarely handle presentation alone. They often include data fetching, state management, event handling, and other logic related to user flows. As a result, the responsibilities of the Features layer and the Widgets layer tend to overlap.
This overlap makes it difficult to decide whether a particular piece of code belongs in Features or Widgets. As a project grows, the boundary between the two layers can become even less clear.
For this reason, the updated documentation removes Widgets from the default layer structure. Most code that would previously have been placed in Widgets should instead be organized in Features around user flows and actions. Depending on its responsibility, some code may also belong in App when it is related to application-wide composition or initialization. Code that is reusable and independent of business context may belong in Shared.
There are still cases where Widgets previously provided a natural place for composing multiple Features into a complex UI flow. In these situations, the documentation will recommend considering other composition approaches first. This may include composing the Features in a higher layer, separating responsibilities differently, or exposing interfaces that allow each Feature to be composed externally.
The Widgets related content in the Code Smells & Issues section will remain for now. This content may still be useful for projects that already use the Widgets layer and need guidance on related problems.
Please feel free to leave a comment if you have any questions, suggestions, or concerns about this PR.