alfonsogarciacaro / fable-vue

Fable bindings for Vue.js
35 stars 2 forks source link

Embrace .vue files? #4

Open alfonsogarciacaro opened 6 years ago

alfonsogarciacaro commented 6 years ago

Apparently Vue promotes writing components in a single file with .vue extension mixing HTML, JS and CSS. This is not only for aesthetics, using vue-loader you get template precompilation, CSS scoping and HMR support. Luckily you can redirect each part to a different file, so I guess we could do something like this:

<!-- my-component.vue -->
<template>
  <div>This will be pre-compiled</div>
</template>
<script src="./MyComponent.fs"></script>
<style>
body {
   background-color: red;
}
</style>

All the samples use a default export for the component, not sure if it's mandatory. Fable doesn't do default exports by default (pun unintended), but we can make it do so with an attribute.

This is probably not without challenge though as it can mess with the F# project structure. Should we go this road to get the benefits of vue-loader?

Zaid-Ajaj commented 6 years ago

I am all in for .vue files, I wanted to this at first but couldn't find the [<ExportDefault>] attribute that we had before in fable. This puts state management in F# and templating in html which makes using external components easier as you would just import and use them from the <script> tag

alfonsogarciacaro commented 6 years ago

I think I removed ExportDefault when doing the cleanup for Fable 2, but shouldn't be difficult to bring it back in 2.1 (hopefully).

Lanayx commented 6 years ago

For me the reason to switch to fable with vue.js is compile time errors and here I mean compile errors for templates as well. So I'd rather go something like jsx for this from the beginning https://vuejs.org/v2/guide/render-function.html

Zaid-Ajaj commented 6 years ago

The idea with this library is not make a clone of elmish/react with yet another html DSL because they would really be just the same library and I would see no reason why would someone use fable-vue or fable-elmish with react if we did that. We could still have partial support for it but still have full .vue files support

Lanayx commented 6 years ago

@Zaid-Ajaj Let me be more precise - I love Vue's template engine, it's super intuitive and easy to use, but I'm really missing the compile time template errors. Being able to use Vue.js with typed code and templates would be incredible. Therefore if it is impossible to do with Fable and Vue templates, I'm ok to use jsx which is well-known and widespread. One more thing that I love in .vue files is combination of template, code and styles, moving fsharp code to another file makes it less attractive for me. Still the are people who seperate files, but as for my knowledge of Vue community, there are not so many of them.

alfonsogarciacaro commented 6 years ago

I was thinking to start using Vue's templates as this should be shortest path to an MVP, and also because this may appeal to developers that prefer to use a templating system instead of generating the views in code. But you have a very good point @Lanayx in that type-safe templates would be one of the selling points of using a statically typed language like F# with Vue.

After we've finished implementing the rest of the concepts, it shouldn't be very difficult (hopefully) to add helpers to generate the render function in F# (although we cannot use JSX because F# doesn't accept macros). We could have an API similar to Fable.React or take the opportunity to try something new, like @Zaid-Ajaj has been doing for Xamarin.

Lanayx commented 6 years ago

Agree, starting with untyped templates as MVP makes sense. One more thing that I wanted to point out, is that elmish component approach is not native to vue at all, added my suggestion as an approximate prototype in #9