Ah, I really should have put a comment on this function!

Here's my rationale/etc:

Before this patch, we're sending the raw 'folderMeta' structure over the wire directly.  I figured it would be silly to store the account type in ever folderMeta, since that information is normally very clearly attached to an account in the back-end and should not vary.

But the front-end, especially with our lazy loading, has a comparatively weaker understanding of what's what.  And the folder list UI itself is a fairly naive implementation, so I figured it makes sense to expose the accountType on MailFolder.  If the MailFolders had references to their owning MailAccount I could have just followed that link.  Or if MailAPI just always kept a list of the known accounts (and possibly folders) at all times, it could map the folder id to an account on the fly and that would also work.  We're planning to make that change in the future since it turns out that's the kind of info we really want, but I didn't want to make that more extensive change for this bug.

So the simplest solution from my perspective was to pack the accountType in with the rest of the FolderMeta information we are sending over the wire.  If the FolderMeta was a class instance with its own toBridgeWire() method I probably would just have added it there (and maybe we filter out other stuff), but it's an inert structured-clone persisted structure, so that doesn't quite work.  (And it seems odd to try and force them into a class instance type of existence.)


So that's my rationale.  Once we restructure MailAPI to always know the accounts/folders, I do think I'd want to change it up so MailFolders could just know their owning MailAccount and use a getter to suck it out of there or what not.

I'm open to other ways to get the same info across.  Also, suggestions on how detailed a comment makes sense for this :)