feature/projects-all-the-way-down #3323
|
@ -13,9 +13,9 @@
|
|||
:can-write="canWrite"
|
||||
ref="heading"
|
||||
/>
|
||||
<h6 class="subtitle" v-if="parent && parent.project">
|
||||
<router-link :to="{ name: 'project.index', params: { projectId: parent.project.id } }">
|
||||
|
||||
{{ getProjectTitle(parent.project) }}
|
||||
<h6 class="subtitle" v-if="project?.id">
|
||||
<router-link :to="{ name: 'project.index', params: { projectId: project.id } }">
|
||||
dpschen
commented
This won't update dynamically. Should we change the This won't update dynamically. Should we change the `getParentProjects` to a computed `parentProjects` that automatically updates instead?
konrad
commented
I tried to change it but it fails with I tried to change it but it fails with `getAncestors is not a function`. Any idea?
konrad
commented
Actually this does update dynamically when the project changes. I've had a task open, moved the project to another parent project and it updated instantly. Actually this does update dynamically when the project changes. I've had a task open, moved the project to another parent project and it updated instantly.
|
||||
{{ getProjectTitle(project) }}
|
||||
</router-link>
|
||||
</h6>
|
||||
|
||||
dpschen
commented
Don't end with the error sign. Only use it in between two ancestors or as separator to task title if the latter is direclty next to it. Don't end with the error sign. Only use it in between two ancestors or as separator to task title if the latter is direclty next to it.
konrad
commented
But that's what this does? But that's what this does?
|
||||
|
@ -536,26 +536,17 @@ const visible = ref(false)
|
|||
|
||||
const taskId = toRef(props, 'taskId')
|
||||
|
||||
const parent = computed(() => {
|
||||
const project = computed(() => {
|
||||
konrad marked this conversation as resolved
Outdated
dpschen
commented
`getProjectById` returns `undefined` if there is no project with that id. So why not use that directly?
konrad
commented
Done Done
|
||||
if (!task.projectId) {
|
||||
return {
|
||||
project: null,
|
||||
}
|
||||
}
|
||||
|
||||
return projectStore.getProjectById(task.projectId)
|
||||
})
|
||||
|
||||
watch(
|
||||
parent,
|
||||
(parent) => {
|
||||
const parentProject = parent !== null ? parent.project : null
|
||||
if (parentProject !== null) {
|
||||
baseStore.handleSetCurrentProject({project: parentProject})
|
||||
}
|
||||
},
|
||||
{immediate: true},
|
||||
)
|
||||
const project = projectStore.getProjectById(task.projectId)
|
||||
baseStore.handleSetCurrentProject({project})
|
||||
konrad marked this conversation as resolved
Outdated
dpschen
commented
Very bad pattern. A side effect of a computed can lead to various weird issues. Instead there should be a watcher! Why not use
__Very__ bad pattern.
A side effect of a computed can lead to various weird issues. Instead there should be a watcher! Why not use `getProjectById` directly?
```ts
const project = computed(() => projectStore.getProjectById(task.projectId)})
watchEffect(() => {
baseStore.handleSetCurrentProject({
project: project.value
})
})
```
konrad
commented
I don't even know why I moved that into the computed instead of leaving the watcher as it was before. Changed it back now. I don't even know why I moved that into the computed instead of leaving the watcher as it was before. Changed it back now.
|
||||
return project
|
||||
})
|
||||
|
||||
const canWrite = computed(() => (
|
||||
task.maxRight !== null &&
|
||||
|
|
Shouldn't we still show the parent here?
I've changed it now so that is shows this:
(each project is clickable individually)
For a hierarchy like this:
Can't see these images either
Again 404?
This starts to feel like a gitea bug...