These are chat archives for ractivejs/ractive

8th
Feb 2018
Arnaud Dagnelies
@dagnelies
Feb 08 2018 09:47
IMHO, the current biggest problem we face are the deprecated plugins
It would be really great to clean them up, remove the deprecated ones or fix the existing ones
I think less than half of the listed ones work
...there are already so many existing things. Before we move on to make new ones, perhaps we should start cleaning the dust and possibly presenting in a better way.
regarding the REPL example from svelte, I like it too, and ractive had something similar a few years ago before the site was ported. Perhaps it's possible to pimp the ractive playground a little to resurrect that tutorial style. Sometimes, details make a big difference.
Arnaud Dagnelies
@dagnelies
Feb 08 2018 09:53
perhaps I'm talking a bit silly because I'm tired, but the main points should be IMHO:
  • keeping things simple
  • improve/clean/fix instead of making new
  • make some noise outside the community
Demoing the components may also be nice I think. After all, it's nice to just type "<ace />" to have a code editor in a web page.
Arnaud Dagnelies
@dagnelies
Feb 08 2018 10:40
but in the end it's all about personal initiative
and I'm very grateful @evs-chris and @fskreuz that you've brought it so far! A big thank you again!
Simon Layfield
@simonlayfield
Feb 08 2018 10:56
Greeting Ractivians.
*Greetings
So, I was hoping to get some feedback on something. I'm what you might call a slow learner - that is to say I actually come from a design background but a few years ago got pulled in to the development sphere because it allowed me to be creative in a new and different way.
So as you can imagine the minute I think I've got a grip on some of this new(ish) frontend stuff the slightest thing can trip me up.
Anyhoo, I digress.
Simon Layfield
@simonlayfield
Feb 08 2018 11:01
I decided to give a shot at a getting a module bundler working with Ractive in order to give an old project a bit of an overhaul. Now, I pretty much know I've done this the wrong way - but - it works.
I was hoping that if anyone had time to briefly clone and look at this implementation of Ractive + Rollup you might give me an idea of why this is bad (?)
Mainly because I could just leave it this way and forge ahead, but I'm trying to learn and become more understanding of why one way is bad and another way good.
Joseph
@fskreuz
Feb 08 2018 11:13
@simonlayfield Btw, there is an existing rollup-plugin-ractive . Takes in a component file (hipsters call it "SFC" :smile: ) and emits ESM By default. You can literally import MyComponent from './path/to/MyComponent.html' in your modules when using this. The plugin converts the HTML file into a module, and MyComponent is the constructor for that component. If you're ending up building "a module a component", SFCs and this plugin might be of use. And I think you can write ES in the <script> portion too.
File structure, it's probably how I start my Ractive setups - a main.js and a flat directory of component files (which eventually nests).
Joseph
@fskreuz
Feb 08 2018 11:18
Also, instead of express, consider using lite-server.
Simon Layfield
@simonlayfield
Feb 08 2018 11:20
@fskreuz Yeah I saw rollup-plugin-ractive but initially struggled with getting it to work. The resulting repo is really just me using what little knowledge I have to get something working. I'll circle back round and give it another shot because that's the most solid option I guess.
Thanks! I'll checkout lite-server. Would the reason for using this be that express is 'overkill'?
kouts
@kouts
Feb 08 2018 11:25
Question: does rollup support code splitting - async loading like WebPack does?
Joseph
@fskreuz
Feb 08 2018 11:26
@simonlayfield Not really. It's mostly because it already contains most of the things you expect from a "dev server" - serving multiple dirs, live reload, change ports, proxy, etc. And all that is in config, not code.
@kouts I think it recently did.
rollup/rollup#1841
kouts
@kouts
Feb 08 2018 11:27
Thanks @fskreuz I see it's still experimental: https://rollupjs.org/guide/en#experimental-code-splitting
Paul Maly
@PaulMaly_twitter
Feb 08 2018 11:41
@dagnelies I agree with you in most of the cases.
Joseph
@fskreuz
Feb 08 2018 14:45

If you look at the integration page, most, if not all, of them are third-party. Probably 2/3 of those tools have not seen maintenance for 2-3 years. Probably half of them don't work with 0.9, or 0.8 even. If a developer or a tech lead sees that list, they'd probably say "Oh, an actively-developed library with a lot of dead plugins. This is a bad sign, everyone fled. Not good for a long-term project. Let's look at /React/Reactive/Something else 'R' instead."

Our next move should be:

  • Get all the tools and plugins up to date and working with the latest lib.
  • Formulate a workflow that keeps all of them up to date, well tested, well maintained.
  • If needed, adopt plugins and make them "official" so we are not at the mercy of a third-party to update them (or wait a year for a patch to get merged, this isn't Drupal).
  • Document all of the official tools plugins in one place (Webpack does a good job at this with their official docs, one big sidebar full of it).
  • Housekeeping (deprecate, remove, update content, etc.)
  • Then make noise (we can do this along the way, but it would be silly if we had nothing to show).
Arnaud Dagnelies
@dagnelies
Feb 08 2018 15:33
I would also present all plugins with an inline example, for example by clicking on a demo button. This would have two benefits: first people see it in action directly, then we would also quickly notice if a plugin is broken and act accordingly. In the worst case to move it in a deprecated section. As for the noise, some publicity never harms, I find ractive mature enough for that, even if the plugin list is a bit dusty.
*enough mature for that
Arnaud Dagnelies
@dagnelies
Feb 08 2018 16:32
you have now trailers :P
now I'll have to focus on other stuff
this could actually be transformed into a full fledged site with some effort
Joseph
@fskreuz
Feb 08 2018 16:43
Nice :thumbsup:
Chris Reeves
@evs-chris
Feb 08 2018 17:44
very nice!
Paul Maly
@PaulMaly_twitter
Feb 08 2018 19:55

@simonlayfield

I was hoping that if anyone had time to briefly clone and look at this implementation of Ractive + Rollup you might give me an idea of why this is bad (?)

Very strange approach, seems your "components" is just a template strings and it's wierd. They become a actual Ractive components only in main.js all together and it's wierd too. I never seen something like this before, but for me it's doesn't make sense.

I decided to give a shot at a getting a module bundler working with Ractive

To make any module bundler works with regular Ractive components (not SFC) you just able to use any common config of Webpack or Rollup.

Juan C. Andreu
@andreujuanc
Feb 08 2018 20:14
Nice ! well done @dagnelies
That is what i was talking about
a compilation of those examples, might be great for ractive
@fskreuz im also not a fan of starter templates. But a curated list of those templates by other people might be good idea.
Hard to maintain? maybe, but consider the future benefits
More users ractive gets, more chance to find people who can actually help @evs-chris and not just talk like me xD
Joseph
@fskreuz
Feb 08 2018 20:25
We have such list, it's in the docs https://ractive.js.org/integrations/ (PRs welcome btw :smile: ).
A list of outdated things is worrying enough. Making another list of outdated things doesn't really help. Instead of duplicating effort, let's all consolidate everything into one canonical reference.
Juan C. Andreu
@andreujuanc
Feb 08 2018 20:41
Forgot about that list xP
Sure that one i sperfect
Simon Layfield
@simonlayfield
Feb 08 2018 23:14
@PaulMaly_twitter Thanks. I guess I already knew it was weird to be honest - I was just hoping to get an understanding of why. Like I said there are gaps in my knowledge so when one way doesn't work, I'll try another, and another, and then I'll somehow get it working. Now, that might not be ideal from a development perspective because one way is more efficient, or better from a workflow perspective, or more maintainable - but there's little-to-no 'user impact' the way I see it so the main reason for going back and redoing it the better way is more for learning and having a more full understanding of why it's better. But that's kind of hard to pin down unless problems arise that I can see and debug. I really appreciate everyone's feedback and don't expect anyone to walk me through the ABCs. Just trying to improve through feedback as well as trawling the Googles for tutorials.