meteor-activeroute/legacy

Why am I getting expected string, got function?

Closed this issue · 16 comments

faceyspacey commented

I'm getting this issue all of a sudden when visiting a new route I just added:

Exception in template helper: Error: Match error: Expected string, got function in field ["class"]

How could this be?

faceyspacey commented

it seems to be caused by using findOne() instead of find() as the returns of iron router data handlers. The issue went away when i changed it to a plain find() call.

zimme commented

The object returned from the database when using findOne, most likely had a member named 'class" which was a function. The helpers now uses the data context to populate the options which is most likely the cause of this error message.

akiarostami commented

I'm getting error too. I'm using

{{#if isNotActivePath regex='login|password'}}

and I'm getting this error:

Exception in template helper: Error: Match error: Expected string, got undefined in field ["class"]

faceyspacey commented

@zimme that is exactly the issue! ...is there another option? the 'class' property cant change for me--what are my other options to avoid this?

zimme commented

On vacation right now but when i get back ill think about skipping the data context inheritance in favour of a data attribute the way dynamic template does it

zimme commented

I'm not sure what's the best approach to this "problem" is.

  1. Skipping the data context inheritance and inherit from the data attribute instead.
  2. Adding an option className which when set to true will use className instead of class, this would remove the class/className alias which is in place right now.
  3. Inherit from data attribute if available otherwise inherit from data context. Add option to disable data context inheritance.
faceyspacey commented

i have both class and className properties on my objects. So for me only the fist option would work. It does seem precarious relying on the data context for the route.

zimme commented

The reason I added this was to mimic the behaviour of {{pathFor ...}} and {{linkTo ...}} helpers which iron:router provides.

I think I'll just add support for the data attribute and an option to disable data context inheritance.

Sound good?

zimme commented

or maybe it's better to have data context inheritance as opt-in instead? but Meteor do have implicit data context inheritance by default for templates.

faceyspacey commented

Meteor does, but urs is more of an automated solution, which now is assuming maybe too much about people's code. it's probably best to keep it all to what's specifically provided as parameters.

zimme commented

I haven't forgotten about this, I've just been busy with work.

My thinking is that I'll skip the data context inheritance and inherit from data attribute just like Template.dynamic does.

As this is a breaking change I'll release a new major version when this is done, I'll be leaving support for meteorhacks:flow-router behind with this release too. kadira:flow-router is the new package.

jorisroling commented

I run into this because I have a path member. Please make these kind of assumptions about the context an opt-in, or have a decent opt-out.

zimme commented

Hopefully I can get this done tonight, if not it should be done by the end of the week.

jorisroling commented

Would be grand!

On 18 Aug 2015, at 23:05, Simon Fridlund notifications@github.com wrote:

Hopefully I can get this done tonight, if not it should be done by the end of the week.

—
Reply to this email directly or view it on GitHub #35 (comment).

zimme commented

This should be fixed with version 2.3.1. Please ping me here if it's not resolved and I'll reopen this issue.

jorisroling commented

Works... Thanks!