These are chat archives for ractivejs/ractive

7th
Dec 2017
Anatoli Radulov
@avoto
Dec 07 2017 02:32
@PaulMaly_twitter I meant "single file components" - https://github.com/ractivejs/component-spec
@PaulMaly_twitter as far as my usecase, I have the isolated because the component already has some default data (overridden in this case by what the parent wants it to be - optionally). Also - yes, my component has some domain specific logic (event handlers, etc) which is why it is a component vs a partial.
Paul Maly
@PaulMaly_twitter
Dec 07 2017 02:43
@avoto hm, I don't think that it's a good idea. Seems, in this case, we'll not be able to use the components without building tool at all. I develop isomorphic apps with Ractive and have webpack building and packaging for different environments except NodeJS. I don't need any building process on NodeJS right now, but I should do this in your case.

I have the isolated because the component already has some default data

ok, I got it

Paul Maly
@PaulMaly_twitter
Dec 07 2017 02:49
@all, guys! I've just created a new issue about the future of Ractive. Please, check it and put a thumb up if you agree with that. Thanks!
ractivejs/ractive#3160
Anatoli Radulov
@avoto
Dec 07 2017 02:53
@PaulMaly_twitter I was thinking that there can be more than one version where one is is the Ractive component file as per the official spec. In my case I use the component files via RVC (RequireJS). For me there's no build step - ie, components are loaded straight in the browser.
Paul Maly
@PaulMaly_twitter
Dec 07 2017 10:45
Yes, but you still have an additional compilation, just at runtime in the browser. Not so good idea, you know. I use webpack also to pre-parse Ractive's templates in js files. Less unprofitable expenses in the browser.
Paul Maly
@PaulMaly_twitter
Dec 07 2017 10:55
I think the components should be written so that they could work without any compilation at least in one environment. Seems, that ES6 modules still not enough supported, "single file components" is just a custom workaround for Web Components. CommonJS2 is the only modular system which works stable right now and could be compiled for other environments via Webpack.

For any other environments, except NodeJS, we able to build different types of modules using libraryTarget property in Webpack. Possible options:

"var" - Export by setting a variable: var Library = xxx (default)
"this" - Export by setting a property of this: this["Library"] = xxx
"commonjs" - Export by setting a property of exports: exports["Library"] = xxx
"commonjs2" - Export by setting module.exports: module.exports = xxx
"amd" - Export to AMD (optionally named - set the name via the library option)
"umd" - Export to AMD, CommonJS2 or as property in root

For example, module source file could be written in CommonJS2 style, but distributed as UMD module.
Paul Maly
@PaulMaly_twitter
Dec 07 2017 11:51
Possible basic folders structure:
/dist/moduleName.min.js // module output file
/tests/
.babelrc
index.js // module source file
package.json
webpack.config.js
Joseph
@fskreuz
Dec 07 2017 12:29
Also note that one of the nice things about Ractive is that it doesn't force you to a tool, or a structure, or a thought process. Suggesting tool-specific procedures and folder structures would be against its intended design.
The idea of component files isn't just to look like web components. It's actually to abstract the build tooling and leave the developer only to worry about the component. I could be using ractive-load at one point, then switch to Rollup if I really needed to pre-compile and bundle - all without rewriting the component file (maybe a bit, for loader-specific quirks like paths to modules).
I've also used rvc sometime ago. We developed with everything on runtime and basically didn't have a build step. But on deploy, we used RequireJS's optimizer. When you use the optimizer with rvc, rvc will precompile the component (templates into AST, scripts into modules, etc.).
Joseph
@fskreuz
Dec 07 2017 12:40
Also, there are constraints where you can't really do a build step. There are entities who lock down their network to the point that there's no npm and therefore no build tools. You have to choose the right tools and... lo and behold! A runtime-only library in 2017! :tada:
kouts
@kouts
Dec 07 2017 12:51
+1 to what @fskreuz said
kouts
@kouts
Dec 07 2017 13:01
what we could have though is an "official" way of doing some things
this can be very useful for beginners
by "official" I don't mean "restrictive" but just a suggestion
Paul Maly
@PaulMaly_twitter
Dec 07 2017 13:21

@fskreuz

Also note that one of the nice things about Ractive is that it doesn't force you to a tool, or a structure, or a thought process. Suggesting tool-specific procedures and folder structures would be against its intended design.

Yes, and I love that! That's why I wrote "possible", just for an example.

It's actually to abstract the build tooling and leave the developer only to worry about the component. I could be using ractive-load at one point, then switch to Rollup if I really needed to pre-compile and bundle - all without rewriting the component file

But you can't use these components without building tool and that's the main problem for me. I develop isomorphic apps and even speak at conferences about it. My isomorphic (shared) code makes about 90% of all application code. It means, my code works the same in browser and NodeJS. It's not so simple, but it works great and I definitely need to be able to use modules in NodeJS without builing tool:

const somePlugin = require('some-plugin');

Also, there are constraints where you can't really do a build step. There are entities who lock down their network to the point that there's no npm and therefore no build tools.

It's not a problem in my approach, because modules already comes with ready-to-use in all environments:

Paul Maly
@PaulMaly_twitter
Dec 07 2017 13:26
// you do this in nodejs
const somePlugin = require('some-plugin');

// you do this in browser
<script src="/dist/somePlugin.min.js"></script>
Basically, you don't need to use building tool at all.
In package.json of module we can switch bowser version automatically:
"browser": "./dist/somePlugin.min.js"
Martin Kolárik
@MartinKolarik
Dec 07 2017 13:29
@PaulMaly_twitter if you want the components compiled to JS for both nodejs and browser, there should just be one UMD version
Paul Maly
@PaulMaly_twitter
Dec 07 2017 13:30
For what?
I don't need UMD version in NodeJS, because here I have only one type of modular system - CommonJS
Martin Kolárik
@MartinKolarik
Dec 07 2017 13:31
but what's the point of two different versions?
if we can have one that works in both environments
Paul Maly
@PaulMaly_twitter
Dec 07 2017 13:34
No two versions. It's source version which works in NodeJS as is, and UMD versions produced from the source, for other, not controllable environments.

if we can have one that works in both environments

Because working with UMD version is not so comfortable in difference from CommonJS version

Martin Kolárik
@MartinKolarik
Dec 07 2017 13:36
btw I also do isomorphic apps but right now I simply load the HTML component files and transform them via rcu (when rendering in node)
Paul Maly
@PaulMaly_twitter
Dec 07 2017 13:36
But you always can simple produce UMD version from source using single command: npm run build
Martin Kolárik
@MartinKolarik
Dec 07 2017 13:36
I think the discussion was about what formats should the components be distributed in
Paul Maly
@PaulMaly_twitter
Dec 07 2017 13:39
Actually, it doesn't matter because including Webpack to you module you give to the user the ability to build any kind of module they need.

btw I also do isomorphic apps but right now I simply load the HTML component files and transform them via rcu (when rendering in node)

And you have the costs at runtime? Why?

Martin Kolárik
@MartinKolarik
Dec 07 2017 13:41
not really
it's a one time thing that happens right after loading the files
Paul Maly
@PaulMaly_twitter
Dec 07 2017 13:42
on start of NodeJS server?
or in time of each request?
Martin Kolárik
@MartinKolarik
Dec 07 2017 13:43
technically I load the templates "as needed" so it isn't necessarily right after start of the server, but it's once per component during lifetime of the nodejs process
Paul Maly
@PaulMaly_twitter
Dec 07 2017 13:45
Could you please provide small peace of the code to describe this process?
Paul Maly
@PaulMaly_twitter
Dec 07 2017 13:50
jsdelivr.com uses Ractive, I don't even know about it! Excellent news!
Martin Kolárik
@MartinKolarik
Dec 07 2017 13:51
Few years ago I also built https://github.com/MartinKolarik/ractive-render which works in a similar way but uses rvc or ractive-load to handle loading files
that's useful if you use one of those libs for front-end and want everythinig to work the same way on backend as well
I haven't used it for a while though so not sure if it still works with the latest version of ractive

jsdelivr.com uses Ractive

of course it does :D

Paul Maly
@PaulMaly_twitter
Dec 07 2017 13:59

Yea, I saw it. But my approach is a little bit simpler and doesn't have any costs:

const Ractive = require('ractive');

const $$ = new Ractive({
      template: require('./templates/parsed/app')
});

To use this on the server we just start it with a command:
npm run start
which not only run the web-server but also parses all templates and partials to ready-to-use AST.

To use it on client-side we just run the command:
npm run build
and Webpack builds all sources and assets to a public folder, uglify and minify it, split into chunks, etc.

Two commands, no need to additional libs.

of course it does

Excellent! So, maybe you would like to join a discussion about the Ractive's future here: ractivejs/ractive#3160

Martin Kolárik
@MartinKolarik
Dec 07 2017 14:06
templates/parsed/app is also generated by webpack or do you have another process for that?
Joseph
@fskreuz
Dec 07 2017 14:07

fwiw, aside from component files, I write my components this way and stick it into Buble+Rollup

import Ractive from 'ractive'

export default Ractive.extend({
  template: `
    <div>moar stuff</div>
  `
})

Not pre-compilable at its current state (needs code mangling to find template in the correctly, among other things) but working on something to do this for me. :grin:

It's almost zero-friction, since it's all JS. Buble takes care of the ES, Rollup takes care of the modules, and I usually output an IIFE and stick it to the HTML.
Paul Maly
@PaulMaly_twitter
Dec 07 2017 14:10

@MartinKolarik

templates/parsed/app is also generated by webpack or do you have another process for that?

Simple js file with Ractive.parse() ))))

Martin Kolárik
@MartinKolarik
Dec 07 2017 14:12
oh so you have just templates, not components?
because my files also import other components and contain some component JS
Paul Maly
@PaulMaly_twitter
Dec 07 2017 14:12

There is one more command:

npm run deploy

which do all these things together, so you don't even worry about it.

oh so you have just templates, not components?
no, I don't use "single file components" indeed, but I use components very densely
but I use it in very common way:
Martin Kolárik
@MartinKolarik
Dec 07 2017 14:14
I see...
Paul Maly
@PaulMaly_twitter
Dec 07 2017 14:14
const Ractive = require('ractive');

const $$ = new Ractive({
      template: require('./templates/parsed/app'),
      components: { 
            child: require('./components/Child')
      }
});
Martin Kolárik
@MartinKolarik
Dec 07 2017 14:15
importing other components, some component js, sometimes require to load other js files
Paul Maly
@PaulMaly_twitter
Dec 07 2017 14:15

my templates usually look like this:

it's not a just templates, it's "single file components", approach which comes from Web Components spec, and used by Riot/Vue etc

Martin Kolárik
@MartinKolarik
Dec 07 2017 14:17
yeah but the point is - that's why my approach is more complicated
Paul Maly
@PaulMaly_twitter
Dec 07 2017 14:18
I don't use this approach because it little bit weird to me - all stuff in one big file, like PHP did before.
Martin Kolárik
@MartinKolarik
Dec 07 2017 14:19
yep, I like that :D
Paul Maly
@PaulMaly_twitter
Dec 07 2017 14:20
I like to split files by responsibilities, I like to use Mixins and other modular tools
Paul Maly
@PaulMaly_twitter
Dec 07 2017 14:26

@fskreuz

It's almost zero-friction, since it's all JS. Buble takes care of the ES, Rollup takes care of the modules, and I usually output an IIFE and stick it to the HTML.

But you still need to use Babel and Rollup even if you need to run this code in NodeJS. I'm not because my modules already ready-to-use in NodeJS and ready-to-compile with Webpack.

Chris Reeves
@evs-chris
Dec 07 2017 14:40
This is something I still haven't fully considered yet. How do you handle dynamic module loading on the client on the node side? So far it hasn't really been an issue for me because most of my code ends up being back office apps. But thinking about a the Official Router™, isomorphism would need to be covered, and my current approach of System.import doesn't seem like it would work very well on node.
I wish module loading was a higher priority for the standards bodies, because dynamic imports don't work with acorn-based tooling. That's why System.import() rather than import() if you were wondering.
Paul Maly
@PaulMaly_twitter
Dec 07 2017 15:01
require.ensure + it's polyfill for node
Paul Maly
@PaulMaly_twitter
Dec 07 2017 15:11
And of course, webpack code splitting
Paul Maly
@PaulMaly_twitter
Dec 07 2017 16:12
Example from docs:
var a = require("a");
var b = require("b");
require.ensure(["c"], function(require) {
    require("b").xyz();
    var d = require("d");
});
  • a and b are required normally via CommonJS
  • c is depended through the require.ensure array.
    This means: make it available, but don't execute it
    webpack will load it on demand
  • b and d are required via CommonJs in the require.ensure callback
    • webpack detects that these are in the on-demand-callback and
    • will load them on demand
    • webpacks optimizer can optimize b away
      • as it is already available through the parent chunks
Chris Reeves
@evs-chris
Dec 07 2017 17:17
Interesting... I hadn't used webpack at all until fairly recently, so I'm not very familiar with lots of its functionality. It looks like they might be walking away from require.ensure based on their newer docs.
Though dynamic imports aren't actually a thing yet, so... yeah.
Paul Maly
@PaulMaly_twitter
Dec 07 2017 19:00
Yes, require.ensure is the legacy way of doing that, but right now it works well as far as it's possible