documentation
documentation copied to clipboard
chore: add post about cross-imports
Hello everyone! I wrote a short article about cross-imports, which was previously empty. The problem is quite popular among beginners studying the methodology, so I thought that the material would be useful
Deploy request for pr-fsd pending review.
Visit the deploys page to approve it
| Name | Link |
|---|---|
| Latest commit | ac2c49c5b2fe28cfacb62f9c6ba0131c2a5ed29a |
I have added a translation of the article into English, but it needs to be looked at carefully, as my level of English is quite weak.
Hey, sorry it's taking so long to review. Could you please run the Russian language version through https://glvrd.ru/?
The text has a 7.2 on the clarity scale and a 9.2 on the readability scale.
after a little editing the clarity level was raised to 8.2, but in my opinion the text became a little less specific.
Link updated text: https://pastebin.com/TRhPh9MY
@illright Hi, No problem, any formatting commits are welcome. The changes you mentioned are all on point, I've fixed them and clarified where needed.
I took a look at the changes, it seems like the point about the solution "move to a higher layer" is still relevant:
The example in the solution "moving slices to another layer" is a bit of a misuse of the Features layer. cities are not a feature because it's not an action or a user flow. A city is still a business entity, even if we choose not to make a specific entity slice for it. I think we need to provide more context to this example to help the reader understand when it's appropriate to move code higher. ~~I would even suggest renaming this solution to "moving code to a higher layer", since we're not moving slices, we're moving code inside of slices, possibly into a different slice.~~ [that part is fixed]
The issue here is that layers are not interchangeable, because they also have a meaning. For example, a slice "cities" on the Entities layer defines a business entity City — a real-life concept that the app might be working with. A slice with that name wouldn't be appropriate for the Features layer, because a slice on the Features layer defines a feature of the application — an action that a user can take to get some value out of the application. "City" is not an action, it's a concept.
@illright I think I now understand the gist of your proposal. Accordingly, I have made some additional minor edits.
That's better, but now it feels like the example is a bit unrealistic. I can't envision a project where get-locations would be a feature worth extracting. Maybe we can expand the example, for example, by coming up with some actual pages, and then the solution would be to move the code to the page slice?
@illright I agree. The current example was out of touch with reality. I rewrote it to something more familiar.
Sorry that this PR remains unreviewed for so long. The reason is that I'm currently very busy trying to finish the FSD 2.1 release as soon as possible, and this PR needs more review effort that I can provide for now. Rest assured that I remember about this PR, but I will get to it at a later point in time
built with Refined Cloudflare Pages Action
⚡ Cloudflare Pages Deployment
| Name | Status | Preview | Last Commit |
|---|---|---|---|
| pr-fsd | ✅ Ready (View Log) | Visit Preview | 2fa0a553e24df800e176bd496358e8f752393e42 |
I think it's best for both of us if I close this PR. I'm not fully satisfied with the content and I don't have the capacity to guide improvements.
Please accept my apologies for how it all went down.