I can reproduce the issue. This is a bug. Will be fixed by tomorrow.
Btw: there’s also useQuerySingleRecord which automatically returns the first item of the result, like result[0]. E.g. you could write the above code like this:
const filter = useQuerySingleResult(query('filters'))
let search = null
if (filter !== null){
switch(filter.value){
case 'all':
search = null; break;
case "completed":
search = true; break;
case 'active':
search = false; break;
}
}
@janat08 I think you’re replying via email. Just FYI: While I see your email, it’s not showing up in the web interface here. So it’s better to reply in the web ui.
I’ve just published thin-backend 0.10.03 and thin-backend-react 0.10.1. When you’ve updated to these versions, you can do the following:
import { NewRecordBehaviour } from 'thin-backend';
// ...
const todos = useQuery(todoQ, {
newRecordBehaviour: NewRecordBehaviour.PREPEND_NEW_RECORD
})
I just checked it out again. Do you mean the issue is that when you’re on the All tab, and complete an uncompleted task, that this will not trigger a re-order/re-sort?
I think for now we cannot easily change this behaviour. Also from a UX perspective it might be a bit confusing for a user to see an item just disappearing and moving somewhere else (it would need an animation to be clear to the user).
Draft for article. Between the bug, and that it doesn’t try and determine that it already has all the data between filters like all/active/complete, it’s cheap shortcut to local state management. Redux would offer better UX.
Thanks. I just read through the article Looks good.
and that it doesn’t try and determine that it already has all the data between filters like all/active/complete,
For this kind of app it really makes sense to do the filtering on the client side. This would be a bit more in line with how Thin is intended to be used. This would mean zero latency when switching the filters and also avoid the re-order bug you’ve hit.