Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing resolve properties when handle #with with promise #469

Open
DblK opened this issue Sep 4, 2024 · 4 comments · May be fixed by #471
Open

Missing resolve properties when handle #with with promise #469

DblK opened this issue Sep 4, 2024 · 4 comments · May be fixed by #471

Comments

@DblK
Copy link

DblK commented Sep 4, 2024

Blaze: 3.0.0 (2.6.1 worked fine but no promise at that time)
Meteor: 3.0.2

Since my migration of my application to Meteor 3.0, I had few bugs and the one I had a hard time to figure out was with the helper #with in conjunction with a helper with promise.

I expect #with to work like a #if but it not quite there.
The code go through the #with once the promise is resolve however it can not resolve the variable inside.

Let's say, I have a helper returning a promise with :

async computed() {
   const mycall = await something();

  return mycall; // {a: 1, b: 2, c: 3} || null
}

If I use within blaze :

{{#with computed}}
  {{a}} // not working
  {{computed.a}} // working
{{/with}}

But it defeat my use case of using the with helper.

@jankapunkt
Copy link
Collaborator

jankapunkt commented Sep 5, 2024

Thank you @DblK for the report. Can you confirm it already happens in Blaze 2.9.0?

@jankapunkt
Copy link
Collaborator

@DblK I also think it's currently not as easy to reolve under the hood as we'd like it to be. Can you think of using the Async States instead? → https://www.blazejs.org/api/spacebars#Async-States

@radekmie
Copy link
Collaborator

radekmie commented Sep 5, 2024

I think it'd actually be trivial now, as it's very similar to how #if works (#424). I encourage someone to try it themselves, but I can also do that somewhere next week.

@DblK
Copy link
Author

DblK commented Sep 5, 2024

Thank you @DblK for the report. Can you confirm it already happens in Blaze 2.9.0?

No I can not. I updated the whole app from my previous version to meteor 3.

@DblK I also think it's currently not as easy to reolve under the hood as we'd like it to be. Can you think of using the Async States instead? → https://www.blazejs.org/api/spacebars#Async-States

I might be able but that means I have to redo/check my whole app and I have too many screens so it does not seems a good solution for me.

I think it'd actually be trivial now, as it's very similar to how #if works (#424). I encourage someone to try it themselves, but I can also do that somewhere next week.

Thanks for pointing out. My guess was that it should be similar to #if so I will have a look at it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants