Code sharing?

[rigor789]

From @vesper8 on July 8, 2017 18:1

I'm still considering diving deep into trying to use this instead of React Native since my website is fully built-out with vue components already.

But one thing that isn't clear is how your custom renderer deals with html and css. I imagine there's a limit to how much translation you can do between html/css and what nativescript uses for visual elements. So a project who's vue components are heavily tied in to html that's been positioned and styled using bootstrap grids for example.. most or all of that would be lost right? And you'd end up being able to re-use most of the vue logic but would have to replace the layout part by something more native to nativescript?

Am I understanding that correctly?

Copied from original issue: nativescript-vue/nativescript-vue#29

[rigor789]

From @jlooper on July 8, 2017 18:13

Sorry to butt in. :) But hoping we can have a discussion about code sharing using Vue, which is of great interest to me!

Currently there are some seeds that allow code sharing between Angular and NativeScript, in particular this one: https://github.com/TeamMaestro/angular-native-seed

I would be really interested in crafting such a seed for Vue, using the same strategy of (I believe) a build script that forks logic on the front end.

Could it be possible to have a seed that allows re-use of vue logic/services and then allow import of file.vue for web and file.tns.vue for NativeScript? Currently the Angular seeds that allow code sharing follow this strategy (file.html and file.tns.html on the front end, so that you can use NativeScript components for mobile but share almost everything else)

I'd love to see what we could do here. 🥇

[rigor789]

So the problem is that nativescript-vue does not use actual html, just NativeScript specific custom elements. An idea that I have is to allow using the same codebase for web and native by utilizing custom sections in .vue files. So the <template></template> would be used for the web, and a <native></native> (or anything that makes sense) would get used on the NativeScript side. Now this still doesn't solve all the issues, what if there are DOM dependent actions inside <script></script>? My idea is to have an optional section for the <native-script></native-script> where anything can be overridden. Optionally add a prop just like scoped for <style scoped></style> that alters the behavior to not override, but completely replace the scripts defined in <script></script>. This is just an idea, but let me know if it's anything potentially useful.

An example .vue file would look something like this:

<template>
  <div>
    <h1>Hello {{ user }}</h1>
    <button @click="handleClick">Click me!</button>
  </div>
</template>

<native-template>
  <page>
    <label style="font-size: 20">Hello {{ user }}</label>
    <button @tap="handleClick">Click me!</button>
  </page>
</native-template>

<script>
  export default {
    data() {
      return {
        user: 'Foo'
      }    
    }

    methods: {
      handleClick() {
        // SHOW A DOM BASED MODAL
      }
    }
  }
</script>

<script>
  export default {
    methods: {
      handleClick() {
        // Override the web implementation with a native modal.
      }
    }
  }
</script>

[rigor789]

From @jlooper on July 10, 2017 14:18

I am wondering whether, once you start getting into complex xml layouts, the one-file-strategy would get hard to read/hard to maintain. Is there a way to import files, keeping this usage of <native-template> intact?

[rigor789]

I'm guessing src imports would solve that: https://vue-loader.vuejs.org/en/start/spec.html#src-imports

[rigor789]

From @tjvantoll on July 10, 2017 14:32

@vesper8 A simple thing you can do right away is abstract all of your code that doesn’t touch your user interface in any way—things like models, services, business logic and stuff—into its own npm package. Once that code is abstracted you can import it into multiple apps—web or native—as an npm dependency. With that approach you could share a decent chunk of your existing code, although you would have to build up your user interface in NativeScript from scratch (you’re going to have to do that anyways though).

Long term it would be nice to see this sort of code sharing ability built-in, in theory, but as we’ve seen with Angular getting this right is really really hard. Personally I’d rather see nativescript-vue be a really good way to build iOS and Android apps with Vue first, and then worry about how to make the web fit into the equation.

I will say that I agree with @jlooper that I like the idea of splitting up these templates. The problem we’ve seen with Angular code sharing strategies is the complexity can get out of control, so any of these conventions to keep your code structured and modular really helps.

[rigor789]

From @Shepless on September 13, 2017 19:30

@rigor789 @vesper8 A bit late to the discussion here but I have implemented something similar at work but for loading specific templates/styles/scripts based on the device type being built for (mobile/tablet/desktop). The only problem is it depends on webpack and the ability to change the resolve extensions. For example:

If building for desktop the webpack config has the following resolve extensions:

{
   resolve: {
      extensions: [".desktop.js", ".js", ".desktop.json", ".json"]
   }
}

Then our .vue single file component is actually just a proxy to load the correct file based on the resolve extensions. So for example, we would have the following file structure:

+components
+--foo
      +--index.vue
      +--scripts
            +-- foo.desktop.js
            +-- foo.js
      +--templates
            +-- foo.desktop.html
            +-- foo.html
      +-- styles
            +-- foo.desktop.scss
            +-- foo.scss

Then our index.vue file looks like the following:

<template src="templates/foo.html"></template>
<script src="scripts/foo.js"></script>
<style src="styles/foo.scss"></style>

If the desktop build was run then all of the .desktop.* files will be resolved ahead of the .* files. The benefit of this approach is that you can "override" each item as and when needed. So you can just override the script, the template or styles, or all of them as webpack will just fallback to the .* file if there is no extension override.

As I mentioned this is heavily dependent on webpack's ability to resolve extension types in a specific "order". Hope that is of some help.

[rigor789]

@Shepless that is very cool, mind sharing how the workflow feels, since you are loosing the benefits of single-file-components?

[rigor789]

From @Shepless on September 13, 2017 20:14

@rigor789 Honestly - so far it has been great. The trade off has been positive for us as our designs and functionality for platform types are different enough where responsive design and "runtime" overrides would have created far more complexity and obscurity in the code base (not to mention payload bloat). The only real drawback we have found is that our folder structure is denser, but that is something we accept as a reasonable cost for the benefits it gives us.

However, requirements and tastes vary wildly and I completely understand this might not be an approach that fits for everyone but I thought it was worth mentioning in case it was of any use.

I should mention that you could probably get away with proxying just one aspect of the single file component. Where you would just have a resolve extension for your template using .<thing>.html and then the script and style tags remain inside as normal, but I'm not sure if thats confuses matters as you have 2 approaches in play at once.

[rigor789]

From @tralves on September 13, 2017 20:32

@Shepless Great work! This is a huge step forward!

I have a side question about webpack. Did you get live reload working with webpack? Or you have to build and deploy from scratch at each change?

[rigor789]

From @Shepless on September 13, 2017 20:36

@tralves livereload with nativescript-vue? If so then no - I haven't actually used this project yet, I am researching it for potential future projects (and I like it a lot!).

livereload with a web based project? Yes it works fine and with the approach mentioned above we don't need to do any alterations to that process.

[rigor789]

From @damain on February 18, 2018 14:6

Vuejs allows us to make components, so how about creating a component library that sits on top and allows you to display the appropriate view.

Lets say one of the components is nv-image to handle images, the user will type , however in the components template we then use v-if to display or . That way we get the appropriate markup being generated.

This way our users build with one common component library and it works where ever it is placed.
The consideration then would be how do we take the same view and optimise it for larger screens like the desktop

[rigor789]

That concept sounds interesting, but in practice in 99.9% of cases you actually want a different layout. Projects that use that approach (weex for example) don't end up being useful, because either the phone version will lack something or the web version, you just can't magically make it behave correctly on the given platform.

[rigor789]

From @tralves on February 18, 2018 14:26

@damain Weex does that and it is a mess. The idea sounds good, but then in practice it doesn't work. I think that one of the strengths of NativeScript is that it embraces the native platform.

[rigor789]

From @damain on February 18, 2018 15:24

Another alternative could be:
template: isNative ? Native template here : Desktop template here

[rigor789]

From @damain on February 18, 2018 15:33

Then we change $start to test if it is native then start the Nativescript app
or pass everything to regular Vue maybe generate the html layout to place the vue app into, the html layout could be defined in another file and passed as a property to $start()

[rigor789]

What you are saying is already possible in the (currently WIP) webpack template, which allows you to define templates for each platform.

Repo for the template: https://github.com/nativescript-vue/nativescript-vue-webpack-template