mirror of
https://github.com/wasp-lang/wasp.git
synced 2024-12-26 10:35:04 +03:00
56 lines
2.4 KiB
JavaScript
56 lines
2.4 KiB
JavaScript
onMount = fetchTasksAction()
|
|
|
|
render () {
|
|
button title="refresh" onClick = fetchTasksAction
|
|
button title="onlyDoneTasks" onClick = fetchOnlyDoneTasksAction
|
|
return tasks
|
|
}
|
|
|
|
connect(state)
|
|
tasks: () => getTasksSel(state)
|
|
onlyDoneTasks = () => ...
|
|
fetchTasksAction: fetchTasksAction
|
|
|
|
|
|
|
|
|
|
|
|
render () {
|
|
tasks = if nesto then doQuery(GET_TASKS, args) else doQuery(GET_TASKS, other args)
|
|
return tasks
|
|
|
|
|
|
|
|
// Problem?: We fetch all queries before component even starts, we don't fetch them lazily. Could we solve that with annotations like @default, @required and similar? So those would say: don't load it upfront, or do load it upfront, or use this as default value until something is loaded, ...
|
|
// Another problem: While in Redux and Apollo, dev can choose when and under which condition to fetch certain pieces of state,
|
|
// while we say: this is what needs to be fetched upfront for this component and that is it.
|
|
// Can we solve this by providing user with actions that can run queries? So if they want to manually refresh certain query from the component,
|
|
// they could define an action that calls that query in it (with refetch on true) and then call that action from the component, conditionally or whatever.
|
|
queries: {
|
|
tasks: getTasks(arg) @default([]) @required
|
|
|
|
}
|
|
|
|
render () {
|
|
button title="refresh" onClick = this.props.getTasks(otherArg)
|
|
button title="onlyDoneTasks" onClick = this.props.getOnlyDoneTasks()
|
|
|
|
this.props.tasks
|
|
}
|
|
|
|
// Komponenta slusa i koristi u zivotu x querya, kondicionalno ili kako god. Takodjer i radi odredjene akcije.
|
|
// Sto ako ona zeli neki query na silu pokrenuti / refetchati / refreshati?
|
|
// Sto ako zeli neki query "lazy"/"on demand" izvrsiti -> dakle da se on desi tek kad joj treba, da se ne executa odmah cim se komponenta loada ili nesto.
|
|
|
|
// Sto ako komponenta zeli "na zivo" promijeniti koje querye slusa (na temelju propova ili necega)? ---> TO SE CINI PROBLEM HM.
|
|
// Ostali to rade tako da: ako se promjene propovi komponente, onda imas priliku redefinirati selectore/querye.
|
|
// Da napravimo da definicija vezanih querya ovisi o propovima, da je funkcija propova? A sto je s lokalnim stateom?
|
|
|
|
// This could be solution, but it seems too "black boxed" -> if it is JS black box and it is happening in runtime, how are we going to translate this into smth else?
|
|
queries: (props, state) => {
|
|
return {
|
|
tasks: getTasks(props.taskId)
|
|
}
|
|
}
|
|
|