ractivejs / component-spec Goto Github PK

There is a problem with the following parsed.v check in ractive-load (or rcv) using Ractive v.0.6.1, that gives parsed.v === 2:

if (parsed.v !== 1) {
throw new Error('Mismatched template version! Please ensure you are using the latest version of Ractive.js in your build process as well as in your app');
}

Just out of curiosity :-)

Following this spec an author would write a HTML file with script and style tags, which is then parsed by loaders to create javascript.

Wouldn't it be more easy to create javascript with an accompanying HTML file and have the javascript require the HTML ?
E.g. like its done at: http://paquitosoftware.com/ractive-js-tutorial-creating-the-barebones/

import Ractive from 'ractive';  
import Template from '../../views/layout/search-user.html';

var SearchGithub = Ractive.extend({  
    isolated: true,
    template: Template,

    oninit() {
        this.on('searchUser', (rEvent) => {
            rEvent.original.preventDefault();

            let username = rEvent.context.query;

            console.log('This is the user you want to look up:', username);
        });
    },

    data: {
        query: ''
    }
});

export default SearchGithub;  

This looks more natural to me and does not require all kinds of special loaders to parse HTML with script tags to javascript.

I'm curious to learn what the downside of this approach is in your view.

I've been playing with other module loaders and tools and I'm seeing this convention of files needing to have a unique extension for tools to easily pick them up. JSX has .jsx, TypeScript with .ts, CoffeeScript with .cs, easily done with something like dir/**/*.jsx, dir/**/*.ts, and dir/**/*.cs,

Ractiveify uses, using .ractor .rtv. rvc uses .html. I've seen somewhere, but can't remember, .rv was used. It's all over the place. Should Ractive have a formal extension for the components? Like a .rc or .rac?

It's not clear from out of the specification how to write a single-file component inheriting another one. It seems it's not possible at all. Am I missing something?

Proposal to expand the current component file format to be able to support more workflows and languages. Note that this only talks about the component file's format. How this is implemented and how much gets implemented is still loader-specific.

Container elements

The goal is to simplify both authoring as well as parsing of a component file.

external component      - <link rel="component" href="./path/to/component" id="MyComponent">
external partial        - <link rel="partial" href="./path/to/partial" id="ThatPartial">
external style (css)    - <link rel="style" type="ractive/style" href="./path/to/css/style">
external style (script) - <link rel="style" type="ractive/script" href="./path/to/js/style">

template                - <template>
partial                 - <template id="foo">

style (css)             - <style>
style (script)          - <style type="ractive/script">

component definition    - <script>

Expanding on the more drastic changes:

• <template> now surrounds the template, to be consistent with styles and scripts. These "container" elements facilitate support for writing in languages other than HTML, CSS and JS (i.e. Jade, SCSS, TS) by defining clear boundaries when these snippets start and end.

• <link> is now used to declare all external resources. This way, you don't have to confuse yourself whether to use <link href> or <script src>.

• <style type="ractive/script"> to support function-style css. Your editor will probably yell at you, but then it's nothing a highlighter can't fix (a future goal).

Component definition format

The goal is to modernize and make consistent the component file format.

<!-- CJS -->
<link ... />
<template> ... </template>
<style> ... </style>

<script>
  const jQuery = require('jquery')

  module.exports = {
    ...
  }
</script>

<!-- ESM -->
<link ... />
<template> ... </template>
<style> ... </style>

<script>
  import jQuery  from 'jquery'

  export default {
    ...
  }
</script>

Summary of changes:

• Change component.exports to module.exports to be more coherent with CJS.
• Allow writing in ESM, with the default export being the init options.
• Like before, markup options take precedence over ones defined in the script options.
• CJS will be the universal, run-immediately format. ESM, for the forseeable future, will require a compile.

Hi,

How should I declare partials in my component definition? There is no mention in the spec.

https://github.com/blackgate/ractive-componentify uses:

<link rel="ractive" href="path/to/_mypartial.ract">
{{>mypartial}}

I'm creating my reactive + SystemJS loader (https://github.com/guilhermeaiolfi/ractem) and would like to know the "right" way of doing that.

Thanks.

I have a component using jqueryui - draggable, and there is the option to have what you're dragging be a dom element created at the time of dragging (http://api.jqueryui.com/draggable/#option-helper).

The problem is my component's CSS doesn't apply to this node, because it doesn't have the data-rvcguid attribute.

Can I look that up somewhere and add it manually to my node, or make ractive aware of this new node in some way?

My component like this:

<p></p>
<script>
componet.experts= {
}
</script>

My App has many components,I want to pack them into one file,how to do ?

ractive 0.6.1, ractive-load 0.4.0 , all installed using bower. The HelloWorld example works but once the <script> tag is added to the component html, it does not work, only a blank page.

I realize this is late in the game, but I really hate to learn on my own skin how Ractive, while being the absolute best at bringing 2-way-binding and modularity as just a next step from the 'good old HTML+JS+CSS', still has this rough edge of only allowing a single top level <script> element on single-file components here.
I mean, if not for this one, you really could treat pretty much every HTML content as a starting point for a Ractive component. But here I am, having to either resort to forking the SPF specification, or refactor my HTML views just to hide the scripts into one of the non-top-level elements for no particular reason.

Is there any chance of making the required magic more explicit here and perhaps require a special marker class, say <script class="componentExports">components.exports = { ... }</script> for the script that is supposed to contain the directive?
I really feel this will make more sense, as it would signify that there exist some special syntax requirements and assumptions in that script. The framework will be adopted more widely if it does not put new restrictions to the existent expressibility (although I do think Ractive has been the very best at practicing it!).

If you guys agree, I am happy to write a PR that does this in a backwards compatible way, as I realize it is a must due to existent implementations.

Thanks for considering!

Today I find myself adding a lot of inline partials to various components. This makes the component code difficult to read and follow.

That said I thought that It would be very nice if the component spec allows for a new <link rel="ractivePartial" href="path_to_partial.html" name="myPartial"> which essentially ads the partial into constructor.partials (component.exports).

Lastly I am keen on making the change (here in terms of documenting it and in the RCU repo). @fskreuz if I do so, should I just make a pull request with you as a reviewer?

Of course, I am not going to go ahead with any work until this gets finalized - eg. what should the format of the new partial be, etc.

I'm not sure if this is the best place for this, but I see no way to define css in a component for elements which aren't part of the components template.

I'm trying to use jquery-ui contained within a component file. It works great combined with ractive decorators, but the css doesn't work when embedded in the component, because it's elements aren't part of the template. They are dynamically created by jquery-ui library.

Maybe have an option for appending styles to the main page's style tag? I don't know.