These are chat archives for ractivejs/ractive

13th
Feb 2018
Joseph
@fskreuz
Feb 13 2018 01:50
RFC: ractivejs/component-spec#18 TL;DR: Support ES officially together with the CJS form, consistent referencing of inline-able things, a top-level <template> container, and stuff...
Chris Reeves
@evs-chris
Feb 13 2018 03:24
Does the use stuff solve the Ractive included issue?
Joseph
@fskreuz
Feb 13 2018 03:38
If you mean #14 which i closed in favor of this, I'm a bit skeptical allowing a random script to be linked/embedded/loaded by a component file. Feels like a footgun, there's no guarantees a component file is evaluated just once. I just added <link rel="script" href="./path/to/script" type="ractive/javascript"> in the suggestions to address that, but it's open for interpretation/debate/removal (actually, everything is. It's an RFC after all. :grin: )
Chris Reeves
@evs-chris
Feb 13 2018 03:40
nah, the last item in the issue
SFCs could be forced through use, so the loader doesn't have to sweat where the Ractive comes from?
loader could have a flag to make it global or could just return a function ready to use wherever
Joseph
@fskreuz
Feb 13 2018 03:43
ahh
Just threw that one in for consideration. If everything ends up being monorepo-ized, the Ractive that comes with the loaders should be a compatible version anyways. Soo... non-issue I guess. :grin:
Joseph
@fskreuz
Feb 13 2018 03:51
But yeah, loader-specific things. Spec could just say "The Ractive variable is expected to be available in scope. But what Ractive is depends on your loader, your config, and color of roof." :grin:
Chris Reeves
@evs-chris
Feb 13 2018 04:05
so with the cjs version, the loader shoves in the template and css after processing
how does that work with the esm version?
Joseph
@fskreuz
Feb 13 2018 04:06
Source mangling :D Will bring in acorn and magic-string for that. Replaces export default config with export default Ractive.extend(config, { template, css, stuffFromMarkup })
Chris Reeves
@evs-chris
Feb 13 2018 04:06
ah, gettin' dirty
acorn and magic string are super awesome for that, though
Joseph
@fskreuz
Feb 13 2018 04:07
Yep. Acorn's pretty neat. Once you get indexes, magic-string does the rest.
For CJS, it's similar to how rcu does it, just append to component stuff from markup, prepend the require calls, append module.exports = Ractive.extend(component.exports). Just wrapping.
Joseph
@fskreuz
Feb 13 2018 04:18
And all this will be done in prepared APIs under a package, so all a loader does is call 2-3 functions and you get an ESM/CJS/constructor.
Slawomir Brzezinski
@zlamma
Feb 13 2018 09:17
Hi @fskreuz . Thanks for the proposal. May I ask about:
external partial - <link rel="partial" href="./path/to/partial" id="ThatPartial">
Does it mean it can take any HTML (so, inside of the file doesn't have to be surrounded by <template>), and hence the reason for closing
ractivejs/component-spec#14
?
If that's the reason, then I applaud :)
On a sadder note though. I see you're switching to <template>. Is it not still the case that the content of it needs to be valid HTML? Some really nasty browsers like IE even go so far, that they drop, e.g., every unknown element between <select> and <option>, and I would think it could also not like any of the moustaches or expressions around attributes.
Slawomir Brzezinski
@zlamma
Feb 13 2018 09:26
Although, to be frank, I haven't got a clue why <template> doesn't have a 'non-HTML' option - I simply think it should. So, I would even prefer using a build tool that could hide that nuiscance (change to <script> or encode somewhere - an attribute or JS).
Joseph
@fskreuz
Feb 13 2018 13:25

re: <link rel="partial">, yep. It's just a file with a Ractive template, no surrounding <template>. The use case is to be able to find all these files, parse them to JSON/JS and consume them. This can be done independently on the cli (glob + cli parse), with a build-time loader (readFile + Ractive.parse()), or runtime loader (AJAX + Ractive.parse()). Just had a realization that I can hint more importables/inline-ables this way.

re: <template>, it's a common misconception but it's just a container for the template, not the actual <template> element. It's just to tell the parser "Hey, the contents of this is the component template. Take the contents and send it to Ractive.parse()". <template> never makes it on the page. Also, this doesn't affect how you normally write in-page templates, this is just for the component file format.

Here's an example of what happens. This is an older implementation I was working on. Here's the raw template:

<link rel="ractive" name="MyComponent" href="./path/to/MyComponent.ractive.html">
<link rel="ractive" name="MyOtherComponent" href="./path/to/MyOtherComponent.ractive.html">
<link rel="ractive" name="YetAnotherComponent" href="./path/to/YetAnotherComponent.ractive.html">

<template>
  <div>Hello, {{ user }}!</div>
  <div>Answer to the Ultimate Question of Life, the Universe, and Everything: {{ answer }}</div>
  <div>Expression {{ a + b }}</div>
  <MyComponent />
  <MyOtherComponent />
  <YetAnotherComponent />
</template>

<style>
  div {
    color: red
  }
</style>

<script>
  const answer = require('hhgttg')
  component.exports = {
    data: {
      user: 'World',
      answer: answer
    }
  }
</script>

Here's the intermediate parsed form that is open to modification by pre-processors/loaders (i.e. transpile script code fromTS to JS, style code from SCSS to CSS, replace .ractive.html to .js etc)

{
  "components": [{
    "name": "MyComponent",
    "module": "./path/to/MyComponent.ractive.html"
  },{
    "name": "MyOtherComponent",
    "module": "./path/to/MyOtherComponent.ractive.html"
  },{
    "name": "YetAnotherComponent",
    "module": "./path/to/YetAnotherComponent.ractive.html"
  }],
  "template": {
    "code": "\n  <div>Hello, {{ user }}!</div>\n  <div>Answer to the Ultimate Question of Life, the Universe, and Everything: {{ answer }}</div>\n  <div>Expression {{ a + b }}</div>\n  <MyComponent />\n  <MyOtherComponent />\n  <YetAnotherComponent />\n",
    "map": null
  },
  "style": {
    "code": "\n  div {\n    color: red\n  }\n",
    "map": null
  },
  "script": {
    "code": "\n  const answer = require('hhgttg')\n\n  component.exports = {\n    data: {\n      user: 'World',\n      answer: answer\n    }\n  }\n",
    "map": null
  }
}
Joseph
@fskreuz
Feb 13 2018 13:30
This JSON then gets sent to a builder function that emits a constructor or module. As you can see, the top elements are only containers for this. They never make it past the parser.
Joseph
@fskreuz
Feb 13 2018 13:38
If I'm missing some kind of use case/workflow, please post it in the issue. That way, it doesn't get lost in Gitter. :grin:
Paul Maly
@PaulMaly_twitter
Feb 13 2018 16:48
Question of the day: Is someone using Redux with Ractive? And why you’re doing that?
Arnaud Dagnelies
@dagnelies
Feb 13 2018 17:16
hi there ...i wanted to check something in the docs, and I must confess I got lost
I didn't find what I was looking for, which is kind of a bad sign since I would say I know a little
perhaps we should call the API "reference" instead and split it into several subpages instead of one mega-huge one
Chris Reeves
@evs-chris
Feb 13 2018 17:20
It started out like that, but people complained about not being able to ctrl-f
Joseph
@fskreuz
Feb 13 2018 17:20
There was actually a discussion about that. It used to be separate pages (methods, props, etc.).
Arnaud Dagnelies
@dagnelies
Feb 13 2018 17:20
aha
but there is a search box :/
well, personnally, I prefer separate pages. Otherwise it just looks overloaded/overwhelming
IMHO
Chris Reeves
@evs-chris
Feb 13 2018 17:21
the search box is built into the docs generator and has... questionable utility
Arnaud Dagnelies
@dagnelies
Feb 13 2018 17:22
Additionally to that, information is spread around, which makes it non-trivial to find. Let's say you want to know something about components. The information is spread over the "Getting started", the "API", "Plugins" and "Concepts" ...so basically you jump around looking for some info.
Chris Reeves
@evs-chris
Feb 13 2018 17:22
it matches very loosely, so for many terms, you always get the same set of pages that happen to be the first match
Arnaud Dagnelies
@dagnelies
Feb 13 2018 17:23
the search box also always finds the same huge page :P
Chris Reeves
@evs-chris
Feb 13 2018 17:23
yes, but when the pages were many, it always found the intro and a few others
Arnaud Dagnelies
@dagnelies
Feb 13 2018 17:24
in my case, I was looking for some details for {{>content}} vs {{yield}} but wasn't able to find it.
Chris Reeves
@evs-chris
Feb 13 2018 17:24
I think the goal on the component split is writing vs using
that should be on the API page
bottom of the mustaches heading, unless those entries don't have your answer?
Arnaud Dagnelies
@dagnelies
Feb 13 2018 17:26
perhaps ctrl-F searching is good for power users, but I wonder if it is for newcomers
Joseph
@fskreuz
Feb 13 2018 17:27
The way I see it, there's 4 kinds of users that arrive on the docs: Juniors, Regular users, Plugin authors, and Lost users. :grin: And the top 4 sections (Getting started, API, Plugins, and Support) correspond to those users.
Well, maybe more that 4, but each section is catered to those kinds of people.
Arnaud Dagnelies
@dagnelies
Feb 13 2018 17:28
ok, I would never have thought to look these up in the mustache section, it's definitely a component specific topic!
Joseph
@fskreuz
Feb 13 2018 17:28
For instance, if I wanted to know internals, Concepts page should be the page I should be and I can read top-to-bottom without jumping pages.
Arnaud Dagnelies
@dagnelies
Feb 13 2018 17:29
Indeed, I more or less got that.
However, from a broader perspective, I wonder if it wouldn't be easier to provide information more "topic based"
For example, a chapter "transitions" with "basics / API / writing plugins / advanced concepts".
Same for other topics. I think it would be more focused. It seems strange to me to jump from one huge page to another huge page, each time reading a few paragraphs of each for the topic at hand.
That being said, what originally brought me to the docs was another topic. I encountered a bug or a limitation right now. I wanted to provide a partial in a component <mycomp>{{>mypartial}}<mycomp> with mycomp template ...{{>content}}... didn't worked. Bug or known limitation?
Joseph
@fskreuz
Feb 13 2018 17:33
Topic-based grouping is good for tutorials, but bad for documenting APIs. An example is Angular's docs. A lot of times, I find myself in a page discussing about unicorns and 6ft-deep examples, when I only wanted to know what this function does, what its params are, examples of usage, etc.
Arnaud Dagnelies
@dagnelies
Feb 13 2018 17:37
lol, editing the doc page is not trivial either :laughing:
Joseph
@fskreuz
Feb 13 2018 17:38
Yup, that was a welcome trade-off. You're not always working on those file anyways. 1000-line code, however, is something else. :grin:
Arnaud Dagnelies
@dagnelies
Feb 13 2018 18:01
I know you put quite some effort into the site, and I know it became necessary, so please don't take the coming words too harshly. To be honest, I find the current site quite confusing and overwheling. It basically reads like a huge dictionary. It's really heavy/disturbing as a learning resource. That's a stark contrast compared to the old site, which was IMHO "sexier" because of its nice tutorial, examples and docs divided in small portions. When you wanted to know something, you just looked for the right keyword, and voilà. Here, most of things is in the "phone book API" whose "table of content" on the left already takes up several pages. There is huge potential to make the current site/docs more digestible and "sexy".
...but as one said "Critique is easy, the art is difficult" ...so please don't take it bad. It's already nice to have an up-to-date resource.
Slawomir Brzezinski
@zlamma
Feb 13 2018 19:35
@fskreuz - thanks for the thorough explanation. I originally thought this is good for ractivejs/component-spec#14 , but, now I can see that the new format moves away from similarity to HTML partials
The old format was actually interoperable with many vanilla HTML partials - my ticket was merely trying to extend that to those that had own <script> tags
Slawomir Brzezinski
@zlamma
Feb 13 2018 19:41
Well, I guess, if the new format has desirables, then there's not much I can do. Although I really liked the existent interoperability, and pretty much chose Ractive for that reason.
Very low learning curve from just editing HTML like:
Writing a HTML article and just realized you need to add dynamics? Just stick a <script> tag, define a model for your HTML and start talking through mustache :) One could pretty much start doing a lot of stuff completely without reaching to documentation, just maybe see an exaple of a similar component in the codebase.
Joseph
@fskreuz
Feb 13 2018 20:33
I guess I'm missing something. How does the script talk to the template? Ractive alone doesn't know the meaning of component.exports. Can you explain the workflow more?
Although I do get the part where you can write vanilla HTML/SVG to begin with. But once you start writing the component.exports and mustaches, you'll need a loader at that point.
At that point, your HTML ceases being a plain HTML file and becomes a Ractive component file.
Joseph
@fskreuz
Feb 13 2018 20:50
When you say "vanilla HTML partials", I'm under the impression you're retrofitting some regular HTML into component file templates, yes?
Slawomir Brzezinski
@zlamma
Feb 13 2018 21:32
Indeed, like in the issue I reported. regular HTML partials. I am interested in maximum framework agnosticity in my web content, so I would have most of it written in pure HTML.
but, not agnosticity at cost of readability, so wherever I need the usual patterns of templating/data binding , I had to settle for a framework
Joseph
@fskreuz
Feb 13 2018 21:35
:thumbsup:
Slawomir Brzezinski
@zlamma
Feb 13 2018 21:36
Ractive was perfect in that it was really not different to just adding a <script>, to make the partial come alive - but it would be better than that, in that these partials could even be 'parametrized' etc.

I thought that all of that waas intentional, especially saw it as the result of the framework's motto:

...works for you, not the other way around. It doesn't have an opinion about the other tools you want to use with it. It also adapts to the approach you want to take. You're not locked-in to a framework-specific way of thinking. Should you hate one of your tools for some reason, you can easily swap it out for another and move on with life.

I found the old component model very clever way of staying invisible.
It was trying to look like the old HTML
Slawomir Brzezinski
@zlamma
Feb 13 2018 21:43
But I know I have unusual needs :) I really like to write stuff agnostically, so I can easily change the framework.
Also, I'm less about building web-apps, but more about trying to create an easy publishing system for a developer, where I control all ins&outs - a mix of articles & programming.
I chose Ractive because I knew must've had a similar cause for the start, being developed at Guardian.
Slawomir Brzezinski
@zlamma
Feb 13 2018 21:49
I am also much more concerned about longevity of solutions, without having to change a thing. And also, since it's less about writing apps, I'm not assuming I will do full blown unit testing etc. I rather want to prototype a lot. Hence I'm looking to minimize surface of contact with the framework.
So, I'm probably not the usual user, if that makes sense...
To answer your question precisely, I was actually loading even pure HTMLs as Ractive components.
I would just accept that this is 'the language for dynamic stuff'. If I ever want to introduce some magic into the content, I would just start using the magic keywords.
Slawomir Brzezinski
@zlamma
Feb 13 2018 21:59
But frankly, this is all 'in progress at home'. I've had too many things going to mature it, but I am slowly building around this idea. Even if Ractive goes another way, I still have the current codebase - against the old Ractive. I can live with that. Just thought that you might be interested in such usage, and see how your framework was kinda unique.
Slawomir Brzezinski
@zlamma
Feb 13 2018 22:08
Does it make it clearer @fskreuz ?
Joseph
@fskreuz
Feb 13 2018 22:11
Yup. :thumbsup:
Slawomir Brzezinski
@zlamma
Feb 13 2018 22:12
Do you think there are better ways of doing what I'm trying to do?
(I should have added, that I also loved the way Ractive was ahead of its time in terms of self-contained, single file, HTML+CSS that wouldn't leak styles. Very helpful in what I was doing. What Rich did was visionary)
Chris Reeves
@evs-chris
Feb 13 2018 22:46
what do you have in your script tags aside from the component definition?
is it content that you're expecting to run once while the component is being loaded, or is it something you expect to be rendered to the DOM with the component?
the latter is still possible with a small extension to the proposed format e.g. <script rel="ractive"> is the component def and any others are added to the template
regarding loading plain html as a component, that's something I definitely would not do
I'd pull that in as plain text and either use a triple in the parent instance (if there is one) or use innerHTML =
Slawomir Brzezinski
@zlamma
Feb 13 2018 22:51
<script rel="ractive"> sounds kinda what I suggested in that
ractivejs/component-spec#14
I said there <script class="componentExports">
Chris Reeves
@evs-chris
Feb 13 2018 22:51
innerHTML remains universal
Slawomir Brzezinski
@zlamma
Feb 13 2018 22:53
regarding multiple evaluation, there was also a question in there. My answer was:
https://github.com/ractivejs/component-spec/issues/14#issuecomment-341999446
Chris Reeves
@evs-chris
Feb 13 2018 22:57
as long as you're ok with ractive rendering a script tag along with the rest of your template, it's not terribly difficult to achieve
Slawomir Brzezinski
@zlamma
Feb 13 2018 22:58
Regarding your solution of innerHTML, I agree it's better for performance etc. But what I need for my authoring solution is that my file organization should be completely devoid of technical distinction between HTML partial and a Ractive component. File organization would only represent semantics and should not leak tech details...
... so, yes the solution could be used, but only if I could detect whether a file is a ractive component, or a basic HTML
if there was that special script marker then yes, it would be achievable
I was hoping to achieve that with the issue
Chris Reeves
@evs-chris
Feb 13 2018 23:00
yes, but I would say it's also not a recommended general practice
it sounds like a preprocessor to the component processor would suite you best
Slawomir Brzezinski
@zlamma
Feb 13 2018 23:01
Sorry, which part is not recommended? not leaking tech-details in filesystem organization?
Chris Reeves
@evs-chris
Feb 13 2018 23:01
pull in the text, wrap the non-component scripts with all of the other html into a template tag, and hand it to the component processor
Slawomir Brzezinski
@zlamma
Feb 13 2018 23:01
Or adding a marker that can allow to tell that file contents are Ractive?
Chris Reeves
@evs-chris
Feb 13 2018 23:02
rendering script tags is generally not recommended
Slawomir Brzezinski
@zlamma
Feb 13 2018 23:09
I can't rule out I will be using vanilla js. Things are still written this way.
you know. $('input').whateverUiPrettyfier(), but I would anticipate much more 'needy' reason
but yes, I would not require you guys to handle this
I was planning to do a pre-processor, come up with something to do with any other 'vanillaJS' scripts, if I ever needed a non-Ractive bit.
And here's the thing where, with the old format, I tried to have you guys make the Ractive <script> special, so I don't need to rely on silly Regex looking for component.exports.
Slawomir Brzezinski
@zlamma
Feb 13 2018 23:15
I could detect that I've got a Ractive component, and turn into whatever it needs to be to work.
but in the old format it would be very little work - just those inline scripts - apply them somehow after loading or something
Now, with the new format, I need the preprocessor to translate my files to Ractive components.
(that's because I really need them simple. I don't want to rewrite the whole file, reindent, add templates and whatever boilerplate around, just because I had an idea to add some interactive bit to the article. I liked when all I needed to add was that Ractive bit, and start using mustache in the existing HTML)
Slawomir Brzezinski
@zlamma
Feb 13 2018 23:20
so, I'm left with the whole idea of similarity to HTML, 'just add a special script tag with some Ractive magic', alone :)
which is life :)
Slawomir Brzezinski
@zlamma
Feb 13 2018 23:26
but I am just sharing my love for that idea, as maybe if you realized someone found this the best (or most unique) feature of Ractive, you won't actually want to pour it with the bath :)
Joseph
@fskreuz
Feb 13 2018 23:31

I was wondering, assuming your partials are never really Ractive components (thus never have use for <script>), what stops you from putting the script in that lone <script> that current tools allow? Current tools only wrap the extras around the script:

var Ractive = require('ractive')
var component = { exports: {} }

// <script> contents

component.template = {}
component.css = ''
module.exports = component.exports

You can potentially do jQuery.getScript() in there to load the external script instead of having an actual extra tag.

Load order is probably another thing, but yeah. :D
Just some random thought :D
Slawomir Brzezinski
@zlamma
Feb 13 2018 23:39
uhh... processing
A bit confused by the number of script words in the first sentence :)
whatever you suggest, I need it to be done without compromising the content format, so in the preprocessor
Slawomir Brzezinski
@zlamma
Feb 13 2018 23:48
at the same time, I am actually not ruling out that my Ractive components, after being initialized, don't do some kind of:
someObscureVanilaJsLibraryThatHasNoMatchInAppFrameworks.applyOnElement(querySelector("whatever it takes to find the instance of the node that was just inserted - and don't assume only one exists on the plage"))
(but I'd take care of that part, if I really ever find a need)
Slawomir Brzezinski
@zlamma
Feb 13 2018 23:57
But it would just be much easier for me if the format stayed, and, to quote my 2-year old sentence:
"Introducing a simple marker for the 'special' script would keep Ractive SPCs really just a graceful superset of plain old HTML."