Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

🧐 Research a new solution for file management

オープン
  • 何か問題がありますか？
#1,586 コメント 2 件 リアクション 0 件 担当者 1 名 GitHub で見る

@FastestMolasses がすでに取り組んでいます。

2024年3月23日 から。

評価

この issue はまだ評価されていません。

説明

performance PRIORITY tests workspace

[!IMPORTANT]
This issue should only be picked up by CodeEdit maintainers

As a CE developer
I want a reliable foundation that handles and manages files
Because it is crucial to other functionality of the application

Our current solution for file managements is reaching its limits and there are some serious bugs present. There has recently been an attempt at writing tests for this part of the code, but it revealed that there is unwanted functionality and results.

Acceptance criteria

  • There has been a thorough investigation on how file management for CodeEdit can be done most effectively
  • The findings have been documented

Scope

In scope
  • Research options on how load a directory recursively as workspace
  • Document the findings of the research (Can be a markdown file)
  • Optionally make PoCs/Demos in a separate project
Out of scope
  • Implement anything of the research done in CodeEdit

Requirements (Might need further refinement)

  • The system should be able to load in a directory recursively from disk
  • It has to be done asynchronously, so no problems occur when a folder is loaded with large amounts of content
  • It should be able to monitor changes in all the files on disk inside that directory, this doesn't include the contents of the file
  • It should be able to add a files and folders to disk

Risks

  • Because CEWorkspaceFileManager and CEWorkspaceFile are referenced at so many places in the codebase, truly refactoring the code might prove difficult. Especially since Xcode's code analysis is plain bad.

Implementation design

Problems with current implementation

There are likely multiple ways to tackle this problem, in terms of using different Apple/Swift APIs and how we design the system ourselves. The latter is the most important and something that we can control. The current setup of CEWorkspaceFileManager and CEWorkspaceFile is not working properly. There are multiple cases where an "IllegalState" is achievable.

One of the reasons this occurs is because currently the CEWorkspaceFile contains all kinds of information, it contains multiple variables & functions related to Git, some that have todo with UI and some that have to do with tab related stuff (Which arguably is also UI). It's not clear what the responsibility of the class is. It doesn't look like the class isn't following the single responsibility principle anymore. Everything that is somewhat related to it, gets "dumped" in there.
It also has some properties that in theory have something to do with it, but from a system design point of view, they don't. An example is fileDocument, from the type CodeFileDocument. You can argue that it should be there because it represents the contents of the file and is therefore related to it. But it actually has more to do with the editor and truly modifying the contents of file. And CEWorkspaceFile represents the file in things like the project navigator, where the contents of the files don't matter.

Another thing that can (and should) be looked at is abstraction. The current CEWorkspaceFileManager and CEWorkspaceFile is referenced everywhere, and is therefore hard coupled to almost everything is the codebase. This also makes it more difficult to make unit tests, as the FileManager can not be mocked or stubbed. It also is a disadvantage in cases like these, be it requires changing all the files/components that rely on it.

Things that are interesting to look into when redesigning

Right now there is one CEWorkspaceFile, which can be either a Folder or a File. Perhaps this is the right way to do and it is how we want it, but another possibility is to make a distinction between the two by making separate classes.

If PoCs are made, it is advised to develop them test driven. Since this is core functionality of the application, we should have tests in place from the get go. This way we know how we want it to behave, before it has been coded.

Tasks

  • Do research for one or multiple solutions (Multiple people can work on this, but should be in contact with each other to prevent duplicate work)
  • Document the findings
  • Discuss findings and PoC's with the team
主要言語
Swift
スター
23.1k
フォーク
1.2k
30日以内にマージされた PR はありません

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

CodeEditApp/CodeEdit のほかの issue

CodeEditApp/CodeEdit の issue をすべて見る

似ている issue

Swift の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。