linkedSignal bug #206
-
Which @ngneat/query-* package(s) are the source of the bug?query Is this a regression?No DescriptionWhen using linkedSignals I've encountered a strange behaviour that I did not encounter with signals and computed. I'm using signal + effect combo from angular 18 as a patchwork solution. Please provide a link to a minimal reproduction of the bugPlease provide the exception or error you saw
Please provide the environment you discovered this bug in
Anything else?No response Do you want to create a pull request?No |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 1 reply
-
|
Beta Was this translation helpful? Give feedback.
-
What i think you're expiriencing here is that your (this) context in your object (
Which in this case, is the objects scope. AuthService{test: {…}}
test: Object
wow: ƒ wow()
name: "wow"
<prototype>: Function
<prototype>: Object
<prototype>: AuthService So to put it simply, accessing |
Beta Was this translation helpful? Give feedback.
-
Thank you for your response, but I've managed to understand more over the span of the afternoon and managed to fix it finally.
which is due to the fact that the functions are actually executed in a context where those fields do not exist. This means that when using this library + computed values (linked, computed...) the order in which things are defined matters a lot. Moving computed signals around ngquery stuff and changing the order will trigger the error!
|
Beta Was this translation helpful? Give feedback.
Thank you for your response, but I've managed to understand more over the span of the afternoon and managed to fix it finally.
While your thesis is really interesting, and eventually lead me to the solution, it is not completely right. I won't lie, I don't understand completely the bug, but I've managed a better working minimal reproduction of the bug (I got really angry not gonna lie)