These are chat archives for ractivejs/ractive

23rd
Oct 2017
Chris Reeves
@evs-chris
Oct 23 2017 02:37
as of edge, the empty data function should no longer be required, as that's now the default rather than an empty object
Cerem Cem ASLAN
@ceremcem
Oct 23 2017 05:45
I'm just wondering, am I the only one who doesn't get the Async component examples?
They seems just too complex to me
Chris Reeves
@evs-chris
Oct 23 2017 05:46
the playground or the tests?
Cerem Cem ASLAN
@ceremcem
Oct 23 2017 05:46
the playground examples
Chris Reeves
@evs-chris
Oct 23 2017 05:46
that's actually a lot more than an async component example
Cerem Cem ASLAN
@ceremcem
Oct 23 2017 05:46
this one, for example
yeah, I just met with Ractive.macro :)
Chris Reeves
@evs-chris
Oct 23 2017 05:47
that also covers the underlying mechanism that handles async components
you don't have to get anywhere near macro to use async components :)
here it is whittled down to just the async component part
Cerem Cem ASLAN
@ceremcem
Oct 23 2017 05:51
what? just that?
Chris Reeves
@evs-chris
Oct 23 2017 05:51
that's all there is to it
Cerem Cem ASLAN
@ceremcem
Oct 23 2017 05:51
hehe :) it's simple? :D
Chris Reeves
@evs-chris
Oct 23 2017 05:51
throw in a promise
and it will eventually swap in the component for you
Cerem Cem ASLAN
@ceremcem
Oct 23 2017 05:55
the line between sync components and async components will be faded soon, I suppose
Chris Reeves
@evs-chris
Oct 23 2017 05:56
the goal of the async support here is that the component absolutely doesn't know or care, so all components are both sync and async once this is live
Cerem Cem ASLAN
@ceremcem
Oct 23 2017 06:33
my intention by using async components is to be able to load components after page load, via socket.io stream. is that the correct way to send an async component over the wire?
Chris Reeves
@evs-chris
Oct 23 2017 06:36
that's quite a bit further than I've ever gone. If I'm using webpack, I just use a dynamic import e.g. import('./path/to/component.ractive.html') or System.import('./path/to/component.ractive.html') and let webpack handle the transfer details.
you could wire something up using socket.io, but it would require doing an eval yourself somehow, which I've avoided up to this point
if I'm not using webpack, I usually just have a self-registering component and use some sort of script tag injection e.g.
function load(path, name) {
  return new Promise(ok => {
    setTimeout(() => {
      var script = document.createElement('script');
      script.src = path;
      script.onload = function() {
        ok(Ractive.components[name]);
      };
      document.body.appendChild(script);
    });
  });
}
Chris Reeves
@evs-chris
Oct 23 2017 06:41
that's the beauty of something like webpack though - it handles the little whacky details for you, though you pay a little bit upfront in the ceremony involved with bundles
Cerem Cem ASLAN
@ceremcem
Oct 23 2017 06:45
I would definitly use webpack if I could understand how it works
Chris Reeves
@evs-chris
Oct 23 2017 06:45
yeah, their docs are a bit of a mess
on my list of things to do is publish a starter repo that uses webpack for async loading of views
it really doesn't help that when you google webpack something 90% of the time you end up in the old webpack 1 docs
Cerem Cem ASLAN
@ceremcem
Oct 23 2017 06:47
hmm. do you think we should prepare a recipe for these kind of stuff, even we use webpack or something else that would handle every detail magically?
Chris Reeves
@evs-chris
Oct 23 2017 06:47
that's the goal
something you can clone and immediately start writing useful code without faffing about with build tools
Cerem Cem ASLAN
@ceremcem
Oct 23 2017 06:48
so a recipe for sending a component over the wire is in our radar?
Chris Reeves
@evs-chris
Oct 23 2017 06:48
yep
Cerem Cem ASLAN
@ceremcem
Oct 23 2017 06:51
I'm a bit confused about the script element approach
do you say using script tag and injecting relevant stuff into it is more appropriate than eval?
Chris Reeves
@evs-chris
Oct 23 2017 06:53
basically, you have scripts on your server that are set up as Ractive.components.MyComponent = Ractive.extend({ ... });. Then when you shove the script element into the document, the browser takes over and handles the rest for you. It's a bit simpler than eval if you ever happen across certain CSPs.
if you don't have to worry about CSPs, then the eval route is probably just as good
Cerem Cem ASLAN
@ceremcem
Oct 23 2017 06:57
okay. I think I'll stick to eval for now (as it works well for me :)
about previous topic, if "recipe for sending a component over the wire" is on our list, "recipe for dependency management" should be on our list too. is that right?
Chris Reeves
@evs-chris
Oct 23 2017 06:59
it is, and webpack does a reasonably decent job at both
Joseph
@fskreuz
Oct 23 2017 12:06

so all components are both sync and async

shrodinger's components :D

Cerem Cem ASLAN
@ceremcem
Oct 23 2017 12:09
ahahah :D
does it mean the anchors are (or will be) obsolete soon?
Joseph
@fskreuz
Oct 23 2017 12:11
From my point of view, it will still be around. Dynamic attach/detach of components has its uses in other places, like routing for example (something I've been wanting to explore) and manual rendering as opposed to pre-defined templating.
Cerem Cem ASLAN
@ceremcem
Oct 23 2017 13:40
I know, we need to test it, but I feel like using promises (thus converting all components to async) may make the app faster (responsive?)
or maybe we could define all components with a random delay (up to 200ms, for example) to reduce the cpu peaks?
Joseph
@fskreuz
Oct 23 2017 14:21
Hmm... First thing that comes into mind is race conditions (harder to debug) and double the render effort (placeholder, then content) upfront. But we'll have to benchmark this to find out. :grin:
Chris Reeves
@evs-chris
Oct 23 2017 14:29
I think the only way it would be significantly faster is if you're doing a bunch of runtime parsing or pulling in a bunch of deps for each component init.
Would definitely make skeleton rendering easier, if that's your thing.
Chris Reeves
@evs-chris
Oct 23 2017 16:54
bit of bikeshedding: what extension should the starter repo use for Ractive files? Up to this point, I've been using .ractive.html, which is nice and explicit and doesn't wholesale take over .html. It does better with syntax highlighting out of the box than .ractive or .ract, but it's also a bit on the long side.
lazylester
@lazylester
Oct 23 2017 16:56
"a bit on the long side" is perfectly ok when it adds clarity, imho
Joseph
@fskreuz
Oct 23 2017 17:05
htmlx :D
Ok, serious this time. .ractive.html isn't so bad considering ng2+ uses .component.html, .component.ts, .service.ts, .router.ts, etc.
kouts
@kouts
Oct 23 2017 17:12
html comes with syntax highlighting out of the box, I mean without having to configure your editor
Joseph
@fskreuz
Oct 23 2017 17:15
there's that too.
Chris Reeves
@evs-chris
Oct 23 2017 17:15
@fskreuz I considered .rhtml just to mess with the rails crowd :laughing:
Joseph
@fskreuz
Oct 23 2017 17:15
rofl
Chris Reeves
@evs-chris
Oct 23 2017 17:17
is it relatively safe to take over .html in most projects? I know there are some other loaders that use it, but I don't know that they would be expected to be mixed into a ractive project
kouts
@kouts
Oct 23 2017 17:17
5 letters (.rhtml) is overkill IMHO :stuck_out_tongue_closed_eyes:
Chris Reeves
@evs-chris
Oct 23 2017 17:18
my concern there is that whatever shakes out here is likely to be the recommended extension for component libraries too
(for those using build tools, it's nice to not have to worry about versioning as much by pulling in the component src)
Joseph
@fskreuz
Oct 23 2017 17:20
I vote for .ractive.html as default but if possible, let the consumer configure it to their taste.
Chris Reeves
@evs-chris
Oct 23 2017 17:21
I'm planning on packaging components as UMD, ES, and src at this point - UMD for those that <script>, ES for those that have whatever module handler, and src for those that have the full build env available
kouts
@kouts
Oct 23 2017 17:22
.ractive.html for me too then
I already use it with ractive-bin-loader
Chris Reeves
@evs-chris
Oct 23 2017 17:22
so no shortening in there? .r.html or .ract.html?
Joseph
@fskreuz
Oct 23 2017 17:31
It's more explicit that way. :D
Plus free PR for the lib :grin:
Chris Reeves
@evs-chris
Oct 23 2017 17:38
I'll call it at .ractive.html as the community has spoken then, and this bike shed shall be a mossy green with 11 slots in 2 sections
Joseph
@fskreuz
Oct 23 2017 17:38
lol
I'd say let it soak for 24 hours. iirc, we have users active 12 hours from now. :D
Chris Reeves
@evs-chris
Oct 23 2017 17:39
true
so tentatively, which is enough for me to start the repo :smile:
Cerem Cem ASLAN
@ceremcem
Oct 23 2017 19:07
:D
Chris Reeves
@evs-chris
Oct 23 2017 19:55
what all should be included in the sample/starter repo? full spa or just basic structure?
Cerem Cem ASLAN
@ceremcem
Oct 23 2017 19:59
will it contain a build system?
Chris Reeves
@evs-chris
Oct 23 2017 20:00
yes
Cerem Cem ASLAN
@ceremcem
Oct 23 2017 20:01
webpack... I vote for basic structure.
kouts
@kouts
Oct 23 2017 20:03
basic structure vs full spa, what's the difference?
Cerem Cem ASLAN
@ceremcem
Oct 23 2017 20:17
I think full spa will cover the router, for example
kouts
@kouts
Oct 23 2017 20:18
Official Router ™ doesn't exist yet, so better go with basic structure then
Cerem Cem ASLAN
@ceremcem
Oct 23 2017 21:02
by the way, what do you think about using github and jsdelivr as a playground backend? like this one: https://github.com/ceremcem/async-component-test
Cerem Cem ASLAN
@ceremcem
Oct 23 2017 21:12
so we can support collaboration, like jsfiddle does
Chris Reeves
@evs-chris
Oct 23 2017 21:26
jsdelivr is quite handy for accessing github repos
on my list of things to do is to have multiple file support in the playground and persistence to gist
I think that would also allow some sort of sane versioning of playgrounds (or whatever the equivalent of fiddles is here)