-
Notifications
You must be signed in to change notification settings - Fork 255
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor server-side folder management implementation #271
Refactor server-side folder management implementation #271
Conversation
Aaawesome! :) Let us know as soon as it’s reviewable! cc @nextcloud/mail |
I have to do some more refactoring before I can finish this one unfortunately, otherwise I'd have to add those ugly unified inbox hacks to the new shiny code too 😢 Should be easy though 😉 |
07f3998
to
ccf8ab9
Compare
@nextcloud/mail this should be ready for a review 🚀 Let me know if something breaks 😉 |
Open todo (though that shouldn't break anything when added back): caching. |
* better OOP architecture * dependency injection everywhere * abstraction where it made sense * SRP applied as much as possible * added a bunch of tests for the new code * REST API compatible to old implementation * new code is not optimized * old code was not removed Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
…p?id=50688 Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
428d933
to
9dcf840
Compare
Please help with testing/reviewing this PR @nextcloud/mail @Quix0r |
That is a long pr! Care to told us how to review? :p |
Yup, sorry 'bout that. Well, just look at the diff 😉 I pretty much re-wrote the old implementation and added a bunch of tests. Unfortunately, I cannot tell you how this could be reviewed easily 😟 |
Sooo, read the js and process it into your head? 😆 |
Sure you can do that hehe Most of the changes were made to the server implementation though. So I basically rewrote the code that handles folder management, which is mainly only about listing folders of an IMAP account. All we do after we got the list is translation, sorting, guessing the folder role and building the folder tree from the source list. To have the most flexibility, maintainability, testability and readability I tried to split the code into logical parts:
The rest of the rather big diff is caused by tests because I almost hit 100% coverage on the new classes (only one little, uncritical if-statement is not covered). Thus you can start at the controller, look what it calls (spoiler: a single method on the manager) and review the delegated functionality in there. Everything should be self-explanatory from the class/method names, or at least that was my intention 😉 Let me know if there's anything else you need to know to understand the changes :-) |
Hmm, |
Been using it today and can’t find any issues so far. :) Any blockers or things to add back in this specific PR? |
@jancborchardt cool, thanks for testing! I think this is ready for merging 😉 |
About the js code coverage: it's not really reliable. It goes up and down. We're not at 33% coverage anyway, the number seems to be wrong :-| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couldn’t find any breakage so far, let’s get it in :)
Perfect! Looking forward to the other unified folders. ;) What can I test next? |
Damn, sorry @ChristophWurst I forgot this one! 😢 |
@ChristophWurst TODO 3 is still open in your list! |
@Quix0r will file an issue right away 🚀 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Already got merged but maybe still good to consider that I have found and maybe then reflect this in next PR.
return undefined; | ||
} | ||
return _.find(this.folders, function(folder) { | ||
// TODO: handle special folders in subfolder properly |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe use @TODO
so documentation tools can pick it up? It is very common though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
makes sense, will use it next time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then maybe apply this globally, e.g. search for // TODO
and replace it with // @TODO
. And same with multi-line comments.
|
||
interface IMailManager { | ||
|
||
public function getFolders(Account $account); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Methods declared in interfaces are always public, no need to have the then redundant public
statement around.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like good practice to always be specific. :)
*/ | ||
public function __construct($appName, IRequest $request, AccountService $accountService, $UserId) { | ||
public function __construct($appName, IRequest $request, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really split this into more than one line? If that is the coding-convention here, okay.
$account = $this->getMockBuilder('OCA\Mail\Account') | ||
->disableOriginalConstructor() | ||
->getMock(); | ||
public function testIndex() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please don't kill doc tags, they produce nice documentation (e.g. generated by doxygen
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean by doc tags?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/**
* Some documented method, does foo things and need bar for its purpose.
* You have to enter a better description than this
*
* @param string $bar Some bar string
* @return void
*/
public function doFoo (string $bar) {
// Do foo things with bar
[...]
}
That is a so called doc-tag. :-) It will produce nice documentation in such tools (see Doxygen
, it can process more than just C/C++). And PHP 7 supports native type-hints. 👍
<?php | ||
|
||
/** | ||
* @author Christoph Wurst <christoph@winzerhof-wurst.at> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you (the team) already made a decision for @copyright
tag? Maybe give it to FSFE so they can handle any law issues for you. Maybe on the developer team (in general) to express that people develop code not for themselves but for the project?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @schiessle
What do you think is best for this project?
$this->assertFalse($this->folder->isSearchable()); | ||
} | ||
|
||
public function testJsonSerialize() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lots of code is missing documentation (what does it do, what is the method foo()
and bar()
for?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's true, many segments of our code are either only documented poorly or not documented at all. We can work on that ofc :-)
@@ -1,81 +0,0 @@ | |||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got rid of an old file? Good. 👍
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and questions. |
I finally found the time to study the server-side implementation and refactor it into a testable, extensible form. This is needed for the planned features like threading. Before I start with those I want the code to be tested almost 100% because testing IMAP manually is a major PITA. This PR shows that moving the existing code a bit around can lead to a much better code quality. Actually, I could even remove some of the code in place because it's just not needed or can be done more efficiently.
TODO:
check why unified inbox flagged folder is not shown any morewell, we never had that feature 🙈