Task Board column header shows the wrong count

[bkohler]

Hi, we have a Task Board component where we have a beforeDestroy listener which will remove a task from the store if a user clicks to add a new task but cancels the edit dialog before entering a name. This is done with the following line of code:

this.taskBoard.project.taskStore.remove(record);

When this happens, the card disappears as expected but the column header still counts the now deleted task in the number of cards in that column. If the user then moves a card, it will correctly update the number in the header so it seems to be recalculating at that point but not when we have called remove() on the taskStore. See the attached video for a demo.

(This is occurring in the LWC environment if it makes a difference.)

Thanks,
Beth

[marcio]

Hey Beth,

Could you please share how did you set up that dialog to add a new task?? I tried to reproduce that with one of our examples but didn't get any luck. We'll need that code to check what could be causing the issue on the video. If you could set up a sample project as well would be great to assist you.

[bkohler]

Hi Marcio,

Our implementation is quite complex so I've created a simplified version of what we're doing from your Customized task editor demo. It will automatically open an editor dialog when you create a task to immediately edit it, and if you clear the name and then click outside of the dialog or cancel it, it will delete the task.

import { TaskBoard } from '../../build/taskboard.module.js?461864';

const taskBoard = new TaskBoard({
	appendTo: 'container',

// Url for resource avatar images
resourceImagePath: '../_shared/images/users/',

features: {
	columnDrag: true,
	taskEdit: {
		editorConfig: {
			autoUpdateRecord: false,
			listeners: {
				beforeDestroy: ({ source: { record, values } }) => {
					if (!values.name) {
						taskBoard.project.taskStore.remove(record);
					}
				}
			}
		},
		items: {
			name: { required: true }
		}
	}
},

columns: [
	{ id: 'todo', text: 'Todo', color: 'pink' },
	{ id: 'considering', text: 'Considering', color: 'purple' },
	{ id: 'doing', text: 'Doing', color: 'lime' },
	{ id: 'done', text: 'Done', color: 'green' }
],

columnField: 'status',

project: {
	loadUrl: 'data/data.json',
	autoLoad: true,
	taskStore: {
		listeners: {
			add: ({ records }) => {
				const newRecord = records.find((record) => record.name === 'New task');
				if (newRecord) {
					taskBoard.editTask(newRecord);
				}
			}
		}
	}
}
});

Unfortunately, I've tried this out on the examples and I can't reproduce the bug so I wonder if it's something specific to the LWC environment (though I'm not sure why that would be the case) or if there's something else in our implementation that's causing the issue.

I've tried to make this example as close to our implementation as I can, but one thing that is different is that we don't have a default value of "New task" for a task on our model class. Instead, new tasks have an empty name when they are first created; again, I doubt this makes a difference but I thought I'd make you aware. (The difference would be that in our add listener in the taskStore it looks for a task with an empty name to know which one to open the editor dialog for, and because the name is a required field and we remove unsaved tasks we can be sure there is only one such task in the store.)

As I mentioned in the original post, the task is removed from the store and the issue seems to be that the headers don't re-render after this happens. The only thing we do around removing tasks is that we have a very simple beforeTaskRemove listener on the taskStore to dispatch an event (this allows us to handle removing the task from the back end in Salesforce).

Hopefully this helps you understand the situation a bit more but if you need more information please let me know.

Thanks,
Beth

[marcio]

Hey Beth,

Thanks for the detailed clarification. Unfortunately, without being reproducible in our demos, it's really difficult to say if it's something on our side. As you mentioned, could be something specific to LWC or something in your implementation.

Just for testing purposes, is it possible to change your implementation to have a default value of "New task"?? Just to check if this is in some way causing that behavior.

Also, pay attention that beforeTaskRemove is asynchronous, which means that you need to wait for some response to properly remove that task without the wrong side effects.