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

[SachaG]

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]

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]

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]

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

[gadicc]

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]

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.