chore: add post about cross-imports

[sanua356]

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

[netlify]

👷 Deploy request for pr-fsd pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	ac2c49c

[sanua356]

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.

[illright]

Hey, sorry it's taking so long to review. Could you please run the Russian language version through https://glvrd.ru/?

[sanua356]

The text has a 7.2 on the clarity scale and a 9.2 on the readability scale.

[sanua356]

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]

Thanks for checking it with Glavred! I agree, these changes aren't that substantial. I have some minor rephrasing suggestions, but we can tackle them at the end.

I like the structure of this article. A defintion of cross-imports, then the solutions, then a bit about what to do if these solutions don't work. Clear and to the point.

I have a few remarks about the examples:

1. 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.
2. In the "merge slices" solution, the name "geography" feels odd to me, I wouldn't use that term to describe a business entity. Perhaps "location" would be a better name?

Another thing I noticed while reading is that there are certain sentences that sound like speech, for example:

Перед тем, как разбираться, как необходимо работать с кросс-импортами для соответствия методологии FSD, необходимо понять, что такое "кросс-импорт" в принципе.

Как разрешать ситуации, когда появилась необходимость сделать кросс-импорт? Рассмотрим в этой статье.

These sentences don't really carry any meaning, they lead into a section. I think that documentation should avoid sentences like this and get straight to the point. I'd suggest removing these.

And the final remark is about the section "What if cross-imports are inevitable". It starts with an admission that it's not the official standpoint of the FSD core-team, but it's in the official documentation, I find that a bit of a contradiction. And it aligns well with the core-team's position, both the @x and lifting the restriction on cross-imports. I'd suggest to instead mention that @x is an experimental proposal (it's going to be standardized soon anyway), and that lifting the restriction is something you should do as a very last resort.

I also have some small formatting corrections, do you mind if I jump on this branch and do them myself? For example, long dashes, list formatting, etc.

[sanua356]

@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.

[illright]

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.

[sanua356]

@illright I think I now understand the gist of your proposal. Accordingly, I have made some additional minor edits.

[illright]

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?

[sanua356]

@illright I agree. The current example was out of touch with reality. I rewrote it to something more familiar.

[illright]

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