These are chat archives for ractivejs/ractive

27th
Jan 2018
Chris Reeves
@evs-chris
Jan 27 2018 03:23
RE: await with both res and err, it looks like finally is finally going to get added to promises, so maybe that's the answer
Juan C. Andreu
@andreujuanc
Jan 27 2018 18:50
@evs-chris moved back to JS. Everything works now. But, SSR does not show components styles. Ill try to debug why, but if you, or any of you guys, can point me to the right direction, it would be great :) thanks
Whooohoo!! Done :) return '<style>' + this.CurrentView.toCSS() + '</style>' + this.CurrentView.toHTML();
Joseph
@fskreuz
Jan 27 2018 18:54

Yeah, there are things classes can't do vs regular functions. "do stuff on extend" is one of them. This could be done with decorators but it's

  • A stage 2 proposal for ES .
  • An experimental feature for TS.
  • Even though we could support it, will force you to use a compile phase.
  • There's little gained from doing export class Foo extends Ractive{ ... } versus export const Foo = Ractive.extend({ ... }).

If you go the decorators route since you're doing TS already, you can probably do write up a simple decorator that takes the extend-time stuff and wrap it around the class or something.

import {Component, Ractive} from 'ractive'

@Component({
  // extend stuff
})
export class MyComponent extends Ractive {
  // instantiation stuff
}
Juan C. Andreu
@andreujuanc
Jan 27 2018 18:54
Thought toHtml returned eveything, but css styles are separate :P
Yes, tried it.
Too much work
Joseph
@fskreuz
Jan 27 2018 18:55
And there's that :D
Juan C. Andreu
@andreujuanc
Jan 27 2018 18:55
1 ) Renamed .ts to .js
2) Change loaders
3) ???
4) Profit
I do miss types, but sometimes its too strict
and i hate decorators xD
Joseph
@fskreuz
Jan 27 2018 18:56
I like how the compiler yells when it thinks you're operating on a null tho :grin:
Juan C. Andreu
@andreujuanc
Jan 27 2018 18:56
xD
Is there any basis for SSR in ractive?
How to maintain state forexample
I was thinkin on a mock state
to "show something" while the real data is loading and stuff
might be enough
Martin Kolárik
@MartinKolarik
Jan 27 2018 22:01
if you do SSR the "real data" should be available immediately on page load, otherwise what's the point of SSR?
Joseph
@fskreuz
Jan 27 2018 22:20
That was sort of the point I was trying to make in the second paragraph of https://github.com/ractivejs/ractive/issues/3176#issuecomment-358708038 . But it seems like there is some form of SSR I'm not aware of. Those characteristics mentioned are eerily identical to the comments in that thread (i.e. render something + fetch data later).
Chris Reeves
@evs-chris
Jan 27 2018 22:24
I don't really see a problem needing to wait on async data, as it would seem logical to have that available before doing the render at the server, no?
Joseph
@fskreuz
Jan 27 2018 22:25
So rendered HTML is non-interactive until data loads and lib renders over/rehydrates the existing HTML?
Chris Reeves
@evs-chris
Jan 27 2018 22:25
If the goal is to pop out a response immediately, then a prerendered placeholder page that fills in after initial load would seem more appropriate e.g. not SSR.
Martin Kolárik
@MartinKolarik
Jan 27 2018 22:26
@fskreuz, the approach @PaulMaly_twitter uses only differs in how he gets data on the server, he does have the state available right away on client
Chris Reeves
@evs-chris
Jan 27 2018 22:27
I was only considering the server side, but yes, I'd expect an SSRed page to know that it needed the data or have it provided as part of the SSR process.
Joseph
@fskreuz
Jan 27 2018 22:27
:thumbsup:
Martin Kolárik
@MartinKolarik
Jan 27 2018 22:30
sometimes I do a partial SSR, rendering only part of the page and placeholders for the rest
mostly useful when you have something that depends on 3rd party API and don't want to query that during SSR for perf reasons
Martin Kolárik
@MartinKolarik
Jan 27 2018 22:36
haven't heard of bigpipe before but yes, that's basically what I meant
exactly as the drupal video shows, it's a great optimization when you have content that can be 99% cached or generated quickly, but there's one little thing that can't and would make everything slow
ractive is very slow for SSR so caching as much as you can is the key
Joseph
@fskreuz
Jan 27 2018 22:48
:+1:
Chris Reeves
@evs-chris
Jan 27 2018 22:51
I haven't ever profiled toHTML... is there anything that jumps out as low-hanging fruit to speed it up?
I know initial render is one of ractive's slowest points, but it's really good at updates
that's not so helpful for ssr
Martin Kolárik
@MartinKolarik
Jan 27 2018 22:53
I think most of the time is spent in the initial setup, not toHTML directly
I was wondering if using static mustaches would provide any perf benefit but haven't had time to test that yet
In theory I could probably replace all {{ with [[ for SSR
Chris Reeves
@evs-chris
Jan 27 2018 22:57
or just swap the delimiter config for ssr?
Martin Kolárik
@MartinKolarik
Jan 27 2018 22:58
that would be easier, indeed
Chris Reeves
@evs-chris
Jan 27 2018 22:59
you're using pre-parsed templates on the server too, though, right?
Martin Kolárik
@MartinKolarik
Jan 27 2018 23:00
yes I cache individual component classes in memory
Paul Maly
@PaulMaly_twitter
Jan 27 2018 23:03
wow, so many line about SSR, great!

to "show something" while the real data is loading and stuff

You mean something like "App Shell" from PWA ? But it's not SSR

Is there any basis for SSR in ractive?

I plan to release "ractive-ready" module after #3182 will be merged in dev. Maybe it will be useful to you.

Martin Kolárik
@MartinKolarik
Jan 27 2018 23:08
@evs-chris won't be as easy as swaping the config because [[#partial foo]] doesn't work
the question is whether there's a good reason for that or it's just that nobody ever tried that
Paul Maly
@PaulMaly_twitter
Jan 27 2018 23:10

@evs-chris

I don't really see a problem needing to wait on async data, as it would seem logical to have that available before doing the render at the server, no?

If you want to have about 95% or more of isomorphic code of your app, you need to write server and client side in the same way. So, I don't thinks so, that you prefetch all data of your client-side app. It's always async story.

Chris Reeves
@evs-chris
Jan 27 2018 23:10
I suspect no one ever tried
Paul Maly
@PaulMaly_twitter
Jan 27 2018 23:12

@fskreuz

So rendered HTML is non-interactive until data loads and lib renders over/rehydrates the existing HTML?

Why? It's just a canonical html page. It will work even if your scripts never come to the client.

My apps could work without js on the client at all.

@evs-chris

If the goal is to pop out a response immediately, then a prerendered placeholder page that fills in after initial load would seem more appropriate e.g. not SSR.

That's called App Shell in PWA. You can see this approach in Slack desktop app

Chris Reeves
@evs-chris
Jan 27 2018 23:17
@MartinKolarik looks like a one(-or-two)-liner to add support for partial defs in template with static delimiters
Paul Maly
@PaulMaly_twitter
Jan 27 2018 23:18

@MartinKolarik

uses only differs in how he gets data on the server, he does have the state available right away on client

Yep, I have all the data that was fetched on the server as an initial state of the client. All that data structured in compliance with components hierarchy

Chris Reeves
@evs-chris
Jan 27 2018 23:19
@PaulMaly_twitter, to be fair, if you have something like an interactive table of data that's paginated, you have to jump through a few extra hoops to have it work mostly the same way with and without client scripts delivered
Martin Kolárik
@MartinKolarik
Jan 27 2018 23:19
yes I already patched parser but now I'm getting this.context.joinKey is not a function in RepeatedFragment.createIteration
not sure if it's related to partials though
Chris Reeves
@evs-chris
Jan 27 2018 23:20
that doesn't sound related to partials
sounds like maybe loopy sections don't support static-ness properly
Paul Maly
@PaulMaly_twitter
Jan 27 2018 23:20
@evs-chris nope
)))
Martin Kolárik
@MartinKolarik
Jan 27 2018 23:22
Paul Maly
@PaulMaly_twitter
Jan 27 2018 23:22
@evs-chris Of course, without JS we lose many interactive features, but basic functionality always work and also we can use fallback of some of interactive things.
For example, if we have js-driven dropdown we'll lose it without js, but we able to show it always opened if so. Not so sweet, but working
Martin Kolárik
@MartinKolarik
Jan 27 2018 23:26
@evs-chris I think static mustaches were only meant to be used for interpolators
Chris Reeves
@evs-chris
Jan 27 2018 23:27
that's what it's looking like to me too, though I'm not sure why they're allowed for other things if that's the case
it doesn't look like it would be too hard to support them though
Paul Maly
@PaulMaly_twitter
Jan 27 2018 23:28

@evs-chris

I was only considering the server side, but yes, I'd expect an SSRed page to know that it needed the data or have it provided as part of the SSR process.

The answer is simple - your SSR code is just the same code as the client code and works exactly the same. Really, it's possible

Chris Reeves
@evs-chris
Jan 27 2018 23:30
@MartinKolarik raises an interesting question though: what exactly does this do [[#each foo]] {{.}} [[/each]]?
my gut says the section never updates, but the interpolator in the middle can if foo.# changes
Martin Kolárik
@MartinKolarik
Jan 27 2018 23:32
throws Uncaught TypeError, that's what it does :laughing:
but really, I don't think static mustaches make sense for sections
Chris Reeves
@evs-chris
Jan 27 2018 23:35
yeah, the way statics are implemented right now is pretty dangerous if the fake model ever gets used for anything other than its value
Paul Maly
@PaulMaly_twitter
Jan 27 2018 23:35

@MartinKolarik

ractive is very slow for SSR so caching as much as you can is the key

How about browser cache and right using of http headers to control that?

Martin Kolárik
@MartinKolarik
Jan 27 2018 23:38
I guess it would make sense if [[#each foo]] meant the loop never re-evaluates foo but can re-evaluate {{.}} but not sure if that's useful for something
Chris Reeves
@evs-chris
Jan 27 2018 23:39
should probably either 1) make it work, 2) disable static sections at the parser level, 3) skip the static flag for sections when it occurs
Martin Kolárik
@MartinKolarik
Jan 27 2018 23:39
@PaulMaly_twitter caching HTML in browser is both dangerous and useless in most cases
Chris Reeves
@evs-chris
Jan 27 2018 23:40
it probably isn't useful, but I could see it popping up with actual support for static sections
Paul Maly
@PaulMaly_twitter
Jan 27 2018 23:47
@MartinKolarik Why? We always use it for static assets, so why we can't use it for pages? I think the main issue how you managing your URLs. If concrete URL is always represents concrete html page - so I think it could be very useful to have browser caching.
Martin Kolárik
@MartinKolarik
Jan 27 2018 23:51
@evs-chris based on some very quick tests I don't see any significant difference in performance
not sure how complicated 1) would be
Chris Reeves
@evs-chris
Jan 27 2018 23:53
that's unfortunate, but I guess not terribly surprising given that the full resolution process and vdom setup still has to take place
Martin Kolárik
@MartinKolarik
Jan 27 2018 23:54
@PaulMaly_twitter taking https://www.nytimes.com/ as an example:
  • you are very unlikely to visit the same page multiple times
  • when they fix a typo in the article or fix a bug in HTML/CSS/JS, they probably want everyone to get the fixed version immediately
Chris Reeves
@evs-chris
Jan 27 2018 23:55
making it work should be as simple as having a slightly better model proxy that passes through to the original model any time anything other than get is called
Martin Kolárik
@MartinKolarik
Jan 27 2018 23:55
I can't imagine a website where: a) the content (and also the code!) never changes, and b) users frequently visit the same page
A nice thing about caching css/js for a long time is that you can force an update by changing HTML when needed, but if you start caching HTML and then need to change anything, you are screwed