DEV Community: Mikaleb

Updating Vue Composition-Api Metas

Mikaleb — Thu, 23 Jul 2020 18:34:55 +0000

After a little head scratch, I found a way to easily update your data if you have a metadata you want to update in a Composition-Api powered Nuxt application, even when they are Async :

<template>
  <div>Your content</div>
</template>

<script lang="ts">
import { defineComponent, ref, onMounted } from '@vue/composition-api'
import usePosts from '~/composables/use-posts'

export default defineComponent({
  name: 'PageArticle',
  head() {
    return {
      title: `${this.title}`,
      meta: [
        { name: 'og:title', content: `${this.title}`, hid: 'og:title' },
      ]
    }
  },

  // eslint-disable-next-line @typescript-eslint/no-unused-vars
  setup(props, ctx) {
    const { fetchArticleForUserLang, article } = usePosts({ ctx })
    const slug = ctx.root.$route.params?.article
    let title = ref('Cuisine De Geek')

    onMounted(async () => {
      await fetchArticleForUserLang({ articleSlug: slug, subcategory: 'article' })
      if (article.value) {
        title.value = article.value[0].title
      }
    })

    return { article, title }
  }
})
</script>

Okay so break-it-down-time :

<template>
  <div>Your content</div>
</template>

Nothing fancy here, just the init of your template content, if you want to display the data (could be a good idea at one point).

<script lang="ts">
import { defineComponent, ref, onMounted } from '@vue/composition-api'
import usePosts from '~/composables/use-posts'

Here, we import the method needed from the composition-api for everything to work correctly : defineComponent, ref to create a dynamic data later, and onMounted to do something as soon as this component/page is called.

The usePosts file called is a separate file I made to handle the logic of loading the data from a separate api (for the record here it's a wordpress REST api).

export default defineComponent({
  name: 'PageArticle',
  head() {
    return {
      title: `${this.title}`,
      meta: [
        { name: 'og:title', content: `${this.title}`, hid: 'og:title' },
      ]
    }
  },

Ah, the big part ! Here, we define the name of our component, then we tell it to change the <head> section of our page.

Because Nuxt use Vue-Meta by default, we can use the head() method in our defineComponent.

Great so now we tell it to use this.title to replace title of the page and og:title. But where do we load this data in particular ?

Well in our setup !

// eslint-disable-next-line @typescript-eslint/no-unused-vars
  setup(props, ctx) {
    const { fetchArticleForUserLang, article } = usePosts({ ctx })
    const slug = ctx.root.$route.params?.article
    let title = ref('Cuisine De Geek')

Here, first I tell eslint to stop bothering me with the fact that I don't use props in this case.
Then i want to get my method fetchArticleForUserLang and the data article that the method will load later.

I store the slug from the route to call the correct article from this slug later and then I set a variable title that is a ref to be able to update it later on a different life cycle of the application :

 onMounted(async () => {
      await fetchArticleForUserLang({ articleSlug: slug, subcategory: 'article' })
      if (article.value) {
        title.value = article.value[0].title
      }
    })

    return { article, title }

When the component or page (here a page), we tell it to be async to be able to await for our method fetchArticleForUserLang to actually find the data and set it to the article variable (all made behind the scene in the usePosts file).

We check that the article have an actual data (.value since it's a ref) then we tell it to assert the value of the title to our brand new article title.

We finish of by returning our article value and our title ET VOILA.

🏕️ The Campfire : a feature analogy

Mikaleb — Tue, 26 Mar 2019 09:22:48 +0000

A few days ago, a friend was asking me why some of the projects I was participating did not finish immediately, or that I sometimes came back to “tweak” them, so I did an analogy that I will share.

First of all, you have to see a project like a campfire: the more we code the basic structures, the more wood we add to our fire. This is what we call an MVP: minimum viable product; the heart of the idea of the project in which we participate.

The larger the campfire, the more contributors around it

As we tend to add features to our project, the critical mass of this fire cannot spread to infinity without creating a mountain of wood and fire that will not be maintainable in the long run without exhausting all the contributors and burning the forest around (burning the resources of the company).

This is why we have to make small campfires (or features) around to always keep the same number of contributors but in the same place, having cut out the number of operations per small camp of x contributors (say for 10, 2 to 5 contributors, so that FnContributors <= 50% of TotalContributors).

Thus, a feature that is being developed today must be similar to a small campfire near the main camp: it must operate independently, the other small fires do not necessarily need the big one (but can improve it), if a relation between two campfire is necessary, it must never impact the main fire by posing a risk of extinction.

It’s time to go melt some marshmallow now, have fun! 🔥

Prez of Mikaleb

Mikaleb — Tue, 04 Apr 2017 08:23:03 +0000

Hey :) I'm Mikaleb, french junior dev, student and trying to specialize in :

PHP (+ Frameworks & cie => Laravel @ this moment)
HTML / CSS (yup front-end)
SQL - NoSQL - PostGre
JS

And I suppose to come up with this presentation with my github : https://github.com/Mikaleb

Thank's !