Error: Inject.obj(id, data [,res]) expects `data` to be an Object or Function

meteorhacks / meteor-inject-initial

Allow injection of arbitrary data to initial Meteor HTML page

Other

78 stars 11 forks source link

Error: Inject.obj(id, data [,res]) expects `data` to be an Object or Function #20

Open SachaG opened 8 years ago

SachaG commented 8 years ago

I've been running into this error (and also Error: Inject.meta(id, data [,res]) expectsdatato be an String or Function when using Inject.meta) when passing a number.

The documentation doesn't make it super obvious what you can or cannot pass, maybe something to clarify?

gadicc commented 8 years ago

Hey @SachaG

We currently provide a general description of the data parameter and document accepted types just by an appropriate identifier name:

data: The data parameter can either be a value, or a function. If a function, it will be called when serving the page to generate appropriate data.
Inject.obj(id, objOrFunc, [res]) on server, accessible via Injected.obj(id) on the client. Obj of course may contain data only, and no references (to functions, other objects, etc).
Inject.meta(id, textOrFunc, [res]), accessible via Injected.meta(id) on client. This is plain text that will be stored in a META tag in the HEAD.

This might be the limit of my documentation skills but I'll happily accept suggestions or PRs on how to make this any clearer.

SachaG commented 8 years ago

The point I wanted to clarify is whether passing a number to Inject.meta would be valid? As far as I can tell it throws an error, I was thinking maybe it shouldn't?

gadicc commented 8 years ago

Yeah that's fair enough :D I'll add this over the weekend. Thanks, Sasha.

gadicc commented 8 years ago

I was thinking about this a little more. I think it might be better to just give an error asking the user to rather pass a string, rather than doing it automatically. Why? Because in META tags we're injecting pure strings, not JSON, so there's no way on the client to know if the user originally passed a string or a number. I'm worried if we did it automatically, the user might forget that they need to convert the string back to a number (I mean, they're work it out eventually... but they could have to deal with some weird coercion issues first, like "2" > "10", etc.).

What are your thoughts about this? And what is your use-case, maybe it could help me frame my thinking more clearly.

SachaG commented 8 years ago

Sure, my use case was passing the server's timezone offset to the client to solve server/client time difference issues. I personally don't see a problem with converting the number to a string automatically, but I'm also fine with keeping it the way it is and just specifying in the docs that it needs to be a string and not a number.