Going to second a response by another person in tfa's comments... who cares.. if it looks right in the source, and renders correctly, I don't see the problem... if it's really a problem, one could always...
console.log(`
<foo>
<bar />
</foo>
`.replace(/$[\r\n]+|[\r\n]+/g,'\n')
or create a function that replaces leading/trailing line feeds, etc with a single line feed.
Comment posted on website:
You need a separate subscriber inside your iframe… I’m guessing you are using <Provide> to wrap your components in the outer window… what you need to do is in the inner window, access the outer store (you’ll need to attach this to the outer window), then from the inner window, use window.parent.store (or whatever name you used), pass that to the iframe’s <provide>
That said, I question the use of an iframe here in general, as it seems you should just be integrating the view into your application.
If you understand how coercion works, you can leverage ==, but for most instances, you should go ahead and be explicit with ===.
The bigger gotchas.
Date (with the same value) won't equate with === as they're separate instances, even if the values match. use (+dtm1 === +dtm2) as this will coerce to a numeric value first.
NaN will not equal NaN... (even with ==), so you will need to account for that (as in above).
There are still a handful of gotchas even with === but they are fewer than with ==.
It's definitely an interesting idea... I could see something like this becoming supported in the browser, and may make sense as an extension to the web components api. It could also be useful as a webpack extension.
Definitely a cleaner approach to rendering than many template libraries. Would appreciate some cleaner examples, and perhaps a flushed out todo-mvc implementation to see a bit more of it.
I don't know that it would replace React + Redux as my preference (though I've now used preact on a few things), but it's nice to see creative options that aren't just re-hashes of what everyone else is doing with just a minor tweak.
A lot of it, yes... but I think the interface is a bit cleaner, and extjs is cumbersome to work with imho. I don't have any use for this, and haven't for a long while, so can't comment. I have written a lot of extjs code in the past, and would rather not look back at it.
I'm happy to see that the JS for the spreadsheet demo (including jquery) is under 1mb... though I still consider 750k to be huge for a JS, for the functionality it isn't bad... Didn't look at the other demos, or interact, was just curious as to the size.
This is not something you would probably want for most public facing sites/applications, one of the larger demos weighed in at 1.7mb of js... again, very impressive for the functionality. I only hope that I can remember about these guys should I ever need this type of functionality again.
Looks like a nice library, but the name doesn't make sense... l10n is short for localization, and i18n is short for internationalization, in that the number replaces that much of the word... x18n, while cute, makes no real sense as a name imho.
It's definitely a better library than many I've seen for the task... that said, a server-side story would be helpful...
x18n(Accept-Language header, default) would make sense, delivering a template instance for that language.
Correction, when ASP.Net came out with its' server-side lifecycle I was enthusiastic, but quickly learned how much of an issue that was in integrating JS responsiveness client-side.
Going to second a response by another person in tfa's comments... who cares.. if it looks right in the source, and renders correctly, I don't see the problem... if it's really a problem, one could always... console.log(` <foo> <bar /> </foo> `.replace(/$[\r\n]+|[\r\n]+/g,'\n') or create a function that replaces leading/trailing line feeds, etc with a single line feed.