Improve item detail fields #1051

mvasilak · 2025-01-09T13:57:33Z

Doesn't show empty fields when editing an item of attachment type.
Properly ends item details editing if no changes have occured when Done is pressed.
Updates date modified for each saved item details change.

michalrentka

Some comments for ItemDetailState.Data struct:

isAttachment in Data should probably a constant? "Normal" item can't become an attachment, so that flag won't ever change.
creators and creatorIds can be converted to OrderedDictionary too.
maxFieldTitleWidth, maxNonemptyFieldTitleWidth don't see to be used anymore, can they be deleted?
should attributedTitle maybe be exluded from equatability of this struct? If for example font size changes (from iOS accessibility settings), the NSAttributedString would differ even if title never changed? It's quite an edge case, but no need to compare attributed string when we already compare the original.

What happens, if the user starts editing, the RItem.changesSyncPaused flag is set to true and then the user crashes at some point while editing? When they open the app, that RItem's sync is still disabled, right? Maybe on app launch/activation we should reset all of these flags to false?

I also noticed a UI bug. When you edit some field and quickly tap "Done", the field change is debounced and since we tap "Done" before the debounce triggers, our UI then shows old state. It's stored in database and synced properly.

michalrentka · 2025-01-10T09:55:39Z

Zotero/Controllers/Database/Requests/EditItemFieldsDbRequest.swift

+    }
+}
+
+struct EditItemFieldsDbRequest: EditItemFieldsBaseRequest, DbRequest {


Is this used anywhere? Why separate into 2 same requests where the distinction is that one returns and the other one doesn't? Can't we just ignore the response when it's not needed?

It's used in PDFReaderActionHandler where it is used in perform(writeRequests: requests), that's why I differentiated them like that. For more streamlining, we can consider changingDbRequest to something like:

protocol DbRequest: DbResponseRequest where Response == Void

michalrentka · 2025-01-10T10:59:58Z

Zotero/Scenes/Detail/ItemDetail/ViewModels/ItemDetailActionHandler.swift

-            }
-
-            self.saveReloaded(data: data, attachments: attachments, notes: notes, tags: tags, isEditing: canEdit, library: library, token: token, in: viewModel)
+            saveReloaded(data: data, attachments: attachments, notes: notes, tags: tags, isEditing: canEdit, library: library, token: token, in: viewModel)


Do we handle the canEdit exception which was there before anyhow?

Yes, since canEdit is passed to saveReloaded as isEditing, it is done directly there, when state.presentedFields are computed.

michalrentka · 2025-01-10T11:02:11Z

Zotero/Scenes/Detail/ItemDetail/ItemDetailDataCreator.swift

-        }
-        return newFieldKeys
+    /// Returns filtered, ordered set of keys for fields that have non-empty values.
+    static func filteredFieldKeys(from fields: OrderedDictionary<String, ItemDetailState.Field>) -> OrderedSet<String> {


Probably worth renaming to something better like nonEmptyFieldKeys or similar.

michalrentka · 2025-01-10T11:13:05Z

Zotero/Scenes/Detail/ItemDetail/ViewModels/ItemDetailActionHandler.swift

+        ) {
+            update(viewModel: viewModel) { state in
+                state.data = data
+                if state.snapshot != nil || isEditing {


Do we need to store snapshot if we're not editing? As far as I can see it's only used in start/end editing, right?

michalrentka · 2025-01-10T11:16:21Z

Zotero/Scenes/Detail/ItemDetail/ViewModels/ItemDetailActionHandler.swift

+                if isEditing && !data.isAttachment {
+                    state.presentedFieldIds = data.fields.keys
+                } else {
+                    state.presentedFieldIds = ItemDetailDataCreator.filteredFieldKeys(from: data.fields)


Is this right? This filters all empty fields and doesn't care about editability of given field. Currently attachments don't have editable fields, but if some editable field was added later, it would not appear for attachment, right? Just to be safe, I'd add a check for editability here (which would be simpler with the isEditable mentioned above).

michalrentka · 2025-01-10T13:22:50Z

Zotero/Scenes/Detail/ItemDetail/ViewModels/ItemDetailActionHandler.swift

@@ -648,16 +648,28 @@ struct ItemDetailActionHandler: ViewModelActionHandler, BackgroundDbProcessingAc
    private func startEditing(in viewModel: ViewModel<ItemDetailActionHandler>) {
        self.update(viewModel: viewModel) { state in
            state.snapshot = state.data
-            state.data.fieldIds = ItemDetailDataCreator.allFieldKeys(for: state.data.type, schemaController: self.schemaController)
+            if !state.data.isAttachment {


Why not just filter out all empty, non-editable fields? For all item types.

If attachment has a URL, it is still shown and it's tappable, even though it's not editable (at least currently).

michalrentka · 2025-01-10T13:45:13Z

Zotero/Scenes/Detail/ItemDetail/ViewModels/ItemDetailActionHandler.swift

-                    var requests: [DbRequest] = [EndItemDetailEditingDbRequest(libraryId: state.library.identifier, itemKey: state.key)]
-                    if !updatedFields.isEmpty {
-                        requests.insert(EditItemFieldsDbRequest(key: state.key, libraryId: state.library.identifier, fieldValues: updatedFields, dateParser: dateParser), at: 0)
+                    let endEditingRequest = EndItemDetailEditingDbRequest(libraryId: state.library.identifier, itemKey: state.key)


So since we're live updating, this is a bit confusing. It made sense before, to have it here, when we had Save + Cancel, but now, not so much.

If you didn't know what this does, when we tap "Done" then fields like "Date" and "Accessed" are converted in some cases, for example if you write "Today" it'll convert to yyyy-mm-dd date format. So this conversion should happen when we're about to store these values to the database, not here.

So we don't even need to update dateModified here and this could be simplified a lot.

michalrentka · 2025-01-10T13:47:40Z

Zotero/Controllers/Database/Requests/EditItemFieldsDbRequest.swift

        }
+
+        return nil


I guess if nothing changed we could throw an error so that you don't have to check whether dateModified is not nil when processing this request. It could possibly help with debugging some time, we log the error, we don't log this being nil.

michalrentka · 2025-01-10T13:50:10Z

Zotero/Scenes/Detail/ItemDetail/ViewModels/ItemDetailActionHandler.swift

-        self.perform(request: request) { error in
-            guard let error else { return }
-            DDLogError("ItemDetailActionHandler: can't store title - \(error)")
+        let request = EditItemFieldsDbResponseRequest(key: viewModel.state.key, libraryId: viewModel.state.library.identifier, fieldValues: [keyPair: viewModel.state.data.title], dateParser: dateParser)


I'd probably compare base strings instead of NSAttributedStrings on line 967 above (same reason as in comment below).

michalrentka · 2025-01-10T13:52:12Z

Zotero/Scenes/Detail/ItemDetail/ViewModels/ItemDetailActionHandler.swift

-            DDLogError("ItemDetailActionHandler: can't store title - \(error)")
+        let request = EditItemFieldsDbResponseRequest(key: viewModel.state.key, libraryId: viewModel.state.library.identifier, fieldValues: [keyPair: viewModel.state.data.title], dateParser: dateParser)
+        perform(request: request, invalidateRealm: false) { [weak viewModel] result in
+            switch result {


This response is repeated in every function which updates specific field, I guess you could extract and re-use it.

mvasilak added 2 commits January 9, 2025 15:54

Fix item detail editing for attachment type

bbffc40

Update Item date modified with each saved change

2d1430f

mvasilak requested a review from michalrentka January 9, 2025 13:57

michalrentka reviewed Jan 10, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Improve item detail fields #1051

Improve item detail fields #1051

mvasilak commented Jan 9, 2025

michalrentka left a comment

michalrentka Jan 10, 2025

mvasilak Jan 10, 2025 •

edited

Loading

michalrentka Jan 10, 2025

mvasilak Jan 10, 2025

michalrentka Jan 10, 2025

michalrentka Jan 10, 2025

michalrentka Jan 10, 2025

michalrentka Jan 10, 2025

michalrentka Jan 10, 2025

michalrentka Jan 10, 2025 •

edited

Loading

michalrentka Jan 10, 2025

michalrentka Jan 10, 2025

Improve item detail fields #1051

Are you sure you want to change the base?

Improve item detail fields #1051

Conversation

mvasilak commented Jan 9, 2025

michalrentka left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mvasilak Jan 10, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

michalrentka Jan 10, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mvasilak Jan 10, 2025 •

edited

Loading

michalrentka Jan 10, 2025 •

edited

Loading