One place for hosting & domains

      Hooks

      Using Git Hooks in Your Development Workflow

      Introduction

      Git, a version control system created by Linus Torvalds, author of the Linux kernel, has become one of the most popular version control systems used globally. Certainly, this is because of its distributed nature, high performance, and reliability.

      In this tutorial, we’ll look at git hooks. These hooks are a feature of git which furthers its extensibility by allowing developers to create event-triggered scripts.

      We’ll look through the different types of git hooks and implement a few to get you well on the way to customizing your own.

      A git hook is a script that git executes before or after a relevant git event or action is triggered.

      Throughout the developer version control workflow, git hooks enable you to customize git’s internal behavior when certain events are triggered.

      They can be used to perform actions such as:

      1. Push to staging or production without leaving git
      2. No need to mess with SSH or FTP
      3. Prevent commits through enforcing commit policy.
      4. Prevent pushes or merges that don’t conform to certain standards or meet guideline expectations.
      5. Facilitate continuous deployment.

      This proves extremely helpful for developers as git gives them the flexibility to fine-tune their development environment and automate development.

      Before we get started, there are a few key programs we need to install.

      1. git
      2. Node.js
      3. bash

      Confirm that you’ve installed them correctly by running the following in your terminal:

      1. git --version && node --version && bash --version

      You should see similar results

      1. git version 2.7.4 (Apple Git-66)
      2. v6.2.2
      3. GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin15)
      4. Copyright (C) 2007 Free Software Foundation, Inc.

      We’ll be using the following directory structure, so go ahead and lay out your project like this.

      +-- git-hooks
          +-- custom-hooks
          +-- src
          |   +-- index.js
          +-- test
          |   +-- test.js
          +-- .jscsrc
      

      That’s all for now as far as prerequisites go, so let’s dive in.

      git hooks can be categorized into two main types. These are:

      1. Client-side hooks
      2. Server-side hooks

      In this tutorial, we’ll focus more on client-side hooks. However, we will briefly discuss server-side hooks.

      These are hooks installed and maintained on the developer’s local repository and are executed when events on the local repository are triggered. Because they are maintained locally, they are also known as local hooks.

      Since they are local, they cannot be used as a way to enforce universal commit policies on a remote repository as each developer can alter their hooks. However, they make it easier for developers to adhere to workflow guidelines like linting and commit message guides.

      Installing local hooks

      Initialize the project we just created as a git repository by running

      1. git init

      Next, let’s navigate to the .git/hooks directory in our project and expose the contents of the folder

      1. cd ./.git/hooks && ls

      We’ll notice a few files inside the hooks directory, namely

      applypatch-msg.sample
      commit-msg.sample
      post-update.sample
      pre-applypatch.sample
      pre-commit.sample
      pre-push.sample
      pre-rebase.sample
      prepare-commit-msg.sample
      update.sample
      

      These scripts are the default hooks that git has so helpfully gifted us with. Notice that their names make reference to git events like pushes, commits, and rebases.

      Useful in their own right, they also serve as a guideline on how hooks for certain events can be triggered.

      The .sample extension prevents them from being run, so to enable them, remove the .sample extension from the script name.

      The hooks we’ll write here will be in bash though you can use Python or even Perl. Git hooks can be written in any language as long as the file is executable.

      We make the hook executable by using the chmod utility.

      1. chmod +x .git/hooks/<insert-hook-name-here>

      Order of execution

      Mimicking the developer workflow for the commit process, hooks are executed in the following hierarchy.

              <pre-commit>
                   |
          <prepare-commit-msg>
                   |
              <commit-msg>
                   |
             <post-commit>
      

      pre-commit

      The pre-commit hook is executed before git asks the developer for a commit message or creates a commit package. This hook can be used to make sure certain checks pass before a commit can be considered worthy to be made to the remote. No arguments are passed to the pre-commit script and if the script exists with a non-zero value, the commit event will be aborted.

      Before we get into anything heavy, let’s create a simple pre-commit hook to get us comfortable.

      Create a pre-commit hook inside the .git/hooks directory like this.

      1. touch pre-commit && vi pre-commit

      Enter the following into the pre-commit hook file

      #!/bin/bash
      
      echo "Can you make a commit? Well, it depends."
      exit 1
      

      Save and exit the editor by running:

      1. esc then :wq

      Don’t forget to make the hook file executable by running:

      1. chmod + x .git/hooks/pre-commit

      Let’s write out some code to test our newly minted hook against. At the root of our project, create a file called hello-world.py:

      1. touch hello-world.py

      Inside the file, enter the following:

      print ('Hello Hooks') 
      
      

      Next, let’s add the file into our git staging environment and begin a commit.

      1. git add . && git commit

      Are you surprised that git doesn’t let us commit our work?

      As an experiment, modify the last line in the pre-commit hook we created from exit 1 to exit 0 and trigger another commit.

      Now that we understand that a hook is just an event-triggered script, let’s create something with more utility.

      In our example below, we want to make sure that all the tests for our code pass and that we have no linting errors before we commit.

      We’re using mocha as our javascript test framework and jscs as our linter.

      Fill the following into the .git/hooks/pre-commit file

      #!/bin/bash
      
      
      num_of_failures=`mocha -R json | grep failures -m 1 | awk '{print $2}' | sed 's/[,]/''/'`
      
      errors=`jscs -r inline ./test/test.js`
      num_of_linting_errors=`jscs -r junit ./test/test.js | grep failures -m 1 | awk '{print $4}' | sed 's/failures=/''/' | sed s/">"/''/ | sed s/\"/''/ | sed s/\"/''/`
      
      if [ $num_of_failures != '0' ]; then
        echo "$num_of_failures tests have failed. You cannot commit until all tests pass.
              Commit exiting with a non-zero status."
        exit 1
      fi
      
      if [ $num_of_linting_errors !=  '0' ]; then
        echo "Linting errors present. $errors"
        exit 1
      fi
      

      Save the document and exit the vi editor as usual by using,

      1. esc then :wq

      The first line of the script indicates that we want the script to be run as a bash script. If the script was a python one, we would instead use

      1. #!/usr/bin/env python

      Make the file executable as we mentioned before by running

      1. chmod +x .git/hooks/pre-commit

      To give our commit hook something to test against, we’ll be creating a method that returns true when an input string contains vowels and false otherwise.

      Create and populate a package.json file at the root of our git-hooks folder by running

      1. npm init --yes

      Install the project dependencies like this:

      1. npm install chai mocha jscs --save-dev

      Let’s write a test for our prospective hasVowels method.

      git-hooks/test/test.js

      const expect = require('chai').expect;
      require('../src/index');
      
      describe('Test hasVowels', () => {
        it('should return false if the string has no vowels', () => {
          expect('N VWLS'.hasVowels()).to.equal(false);
        });
        it('should return true if the string has vowels', () => {
          expect('No vowels'.hasVowels()).to.equal(true)
      
          
          expect('Has vowels'.hasVowels()).to.equal(false);
        });
      });
      

      git-hooks/src/index.js

      
      String.prototype.hasVowels = function hasVowels() {
        const vowels = new RegExp('[aeiou]', 'i');
        return vowels.test(this);
      };
      

      To configure the jscs linter, fill the following into the .jscsrc file we’d created in the beginning.

      .jscsrc

      {
          "preset": "airbnb",
          "disallowMultipleLineBreaks": null,
          "requireSemicolons": true
      }
      

      Now add all the created files into the staging environment and trigger a commit.

      1. git add . && git commit

      What do you think will happen?

      You’re right. Git prevents us from making a commit. Rightfully so, because our tests have failed.
      Worry not. Our pre-commit script has helpfully provided us with hints regarding what could be wrong.

      This is what it tells us:

      1 tests have failed. You cannot commit until all tests pass.
              Commit exiting with a non-zero status.
      

      If you can’t take my word for it, the screenshot below serves as confirmation.

      pre-commit-fail-test

      Let’s fix things. Edit line 13 in test/test.js to

      expect('Has vowels'.hasVowels()).to.equal(true);
      

      Next, add the files to your staging environment, git add . like we did before, and git commit

      Git still prevents us from committing.

      Linting errors present. ./test/test.js: line 10, col 49, requireSemicolons: Missing semicolon after statement
      

      Edit line 10 in test/test.js to

      expect('No vowels'.hasVowels()).to.equal(true);
      

      Now, running git commit after git add . should provide no challenges because our tests and linting have both passed.

      You can skip the pre-commit hook by running git commit --no-verify.

      prepare-commit-msg

      The prepare-commit-msg hook is executed after the pre-commit hook and its execution populates the vi editor commit message.

      This hook takes one, two, or three arguments.

      1. The name of the file that contains the commit message to be used.
      2. The type of commit. This can be message, template, merge, or squash.
      3. The SHA-1/hash of a commit (when operating on an existing commit).

      In the code below, we’re electing to populate the commit editor workspace with a helpful commit message format reminder prefaced by the name of the current branch.

      .git/hooks/prepare-commit-msg

      #!/bin/bash
      
      
      current_branch=`git rev-parse --abbrev-ref HEAD`
      
      echo "#$current_branch Commit messages should be of the form [#StoryID:CommitType] Commit Message." > $1
      

      Running git commit will yield the following in the commit text editor

      #$main Commit messages should be of the form [#StoryID:CommitType] Commit Message.
      

      We can continue to edit our commit message and exit out of the editor as usual.

      commit-msg

      This hook is executed after the prepare-commit-msg hook. It can be used to reformat the commit message after it has been input or to validate the message against some checks. For example, it could be used to check for commit message spelling errors or length, before the commit is allowed.

      This hook takes one argument, that is the location of the file that holds the commit message.

      .git/hooks/commit-msg

      #!/bin/bash
      
      
      
      
      
      commit_standard_regex='[#[0-9]{9,}:[a-z]{3,}]:[a-z].+|merge'
      error_message="Aborting commit. Please ensure your commit message meets the
                     standard requirement. '[#StoryID:CommitType]Commit Message'
                    Use '[#135316555:Feature]Create Kafka Audit Trail' for reference"
      
      
      if ! grep -iqE "$commit_standard_regex" "$1"; then
          echo "$error_message" >&2
          exit 1
      fi
      

      In the code above, we’re validating the user-supplied commit message against a standard commit using a regular expression. If the supplied commit does not conform to the regular expression, an error message is directed to the shell’s standard output, the script exits with a status of one, and the commit is aborted.

      Go ahead. Create a change and try to make a commit of a form other than [#135316555:Chore]Test commit-msg hook

      Git will abort the commit process and give you a handly little tip regarding the format of your commit message.

      commit-msg hook

      post-commit

      This hook is executed after the commit-msg hook and since the commit has already been made it cannot abort the commit process.

      It can however be used to notify the relevant stakeholders that a commit has been made to the remote repository.
      We could write a post-commit hook, say, to email our project team lead whenever we make a commit to the organization’s remote repository.

      In this case, let’s congratulate ourselves on our hard work.

      .git/hooks/post-commit

      #!/bin/bash
      
      say Congratulations! You\'ve just made a commit! Time for a break.
      

      post-checkout

      The post-checkout hook is executed after a successful git checkout is performed. It can be used to conveniently delete temporary files or prepare the checked out development environment by performing installations.

      Its exit status does not affect the checkout process.

      In the hook below, before checkout to another branch, we’ll pull changes made by others on the remote branch and perform some installation.

      .git/hooks/post-checkout

      #!/bin/bash
      
      
      repository_name=`basename`git rev-parse --show-toplevel``
      current_branch=`git rev-parse --abbrev-ref HEAD`present_working_directory=`pwd`requirements=`ls | grep 'requirements.txt' `echo "Pulling remote branch ....."
      git pull origin $current_branch
      
      echo
      
      echo "Installing nodeJS dependencies ....."
      npm install
      
      echo
      
      echo "Installing yarn package ....."
      npm install yarn
      echo "Yarning dependencies ......"
      yarn
      
      echo
      
      
      if [ $present_working_directory == $repository_name ] && [ $requirements == 'requirements.txt']; then
        echo "Creating virtual environments for project ......."
        source`which virtualenv`
        echo
        mkvirtualenv $repository_name/$current_branch
        workon $repository_name/$current_branch
        echo "Installing python dependencies ......."
        pip install -r requirements.txt
      fi
      

      Don’t forget to make the script executable.

      To test the script out, create another branch and check it out like this.

      1. git checkout -b <new-branch>

      pre-rebase

      This hook is executed before a rebase and can be used to stop the rebase if it is not desirable.

      It takes one or two parameters:

      1. The upstream repository
      2. The branch to be rebased. (This parameter is empty if the rebase is being performed on the current branch)

      Let’s outlaw all rebasing on our repository.

      .git/hooks/pre-rebase

      #!/bin/bash
      
      echo " No rebasing until we grow up. Aborting rebase."
      exit 1
      

      Phew! We’ve gone through quite a number of client-side hooks. If you’re still with me, good work!

      Persisting hooks

      I’ve got some bad news and good news. Which one would you like first?

      The bad

      The .git/hooks directory is not tagged by version control and so does not persist when we clone a remote repository or when we push changes to a remote repository. This is why we’d earlier stated that local hooks cannot be used to enforce commit policies.

      The good

      Now before you start sweating, there are a few ways we can get around this.

      1. We can use symbolic links or symlinks to link our custom hooks to the ones in the .git/hooks folder.

      Create a pre-rebase file in our custom-hooks directory and copy the pre-rebase hook we created in .git/hooks/pre-rebase into it. Next, the rm command removes the pre-rebase hook in .git/hooks:

      1. touch custom-hooks/pre-rebase && cp .git/hooks/pre-rebase custom-hooks/pre-rebase && rm -f .git/hooks/pre-rebase

      Next, use the ln command to link the pre-rebase file in custom-hooks to the .git/hooks directory.

      1. ln -s custom-hooks/pre-rebase .git/hooks/pre-rebase

      To confirm that the files have been linked, run the following

      1. ls -la .git/hooks

      The output for the pre-rebase file should be similar to this:

      1. lrwxr-xr-x 1 emabishi staff 23B Dec 27 14:57 pre-rebase -> custom-hooks/pre-rebase

      Notice the l character prefixing the filesystem file permissions line.

      To unlink the two files,

      1. unlink .git/hooks/pre-rebase

      or

      1. rm -f .git/hooks/pre-rebase
      1. We can create a directory to store our hooks outside the .git/hooks directory. We’ve already done this by storing our pre-rebase hook in the custom-hooks directory. Like our other files, this folder can be pushed to our remote repository.

      These are hooks that are executed in a remote repository on the triggering of certain events.

      Is it clear now? Client-side hooks respond to events on a local repository whilst server-side hooks respond to events triggered on a remote repository.

      We’d come across some of them when we listed the files in the .git/hooks directory.

      Let’s look at a few of these hooks now.

      Order of execution

      The server-side hooks we’ll look at here are executed with the following hierarchy.

             <pre-receive>
                   |
                <update>
                   |
             <post-receive>
      

      pre-receive

      This hook is triggered on the remote repository just before the pushed files are updated and can abort the receive process if it exists with a non-zero status.

      Since the hook is executed just before the remote is updated, it can be used to enforce commit policies and reject the entire commit if it is deemed unsatisfactory.

      update

      The update hook is called after the pre-receive hook and functions similarly. The difference is that ii filters each commit ref made to the remote repository independently. It can be used as a fine-tooth comb to reject or accept each ref being pushed.

      post-receive

      This hook is triggered after an update has been done on the remote repository and so cannot abort the update process. Like the post-commit client-side hook, it can be used to trigger notifications on a successful remote repository update.

      In fact, it is more suited for this because a log of the notifications will be stored on a remote server.

      We’ve looked at quite a few hooks which should get you up and running. However, I’d love for you to do some more exploration.

      For a more comprehensive look at git hooks, I’d like to direct you to:

      It’s a brave new world out there when it comes to git hooks, so luckily, you don’t always have to write your own custom scripts. You can find a pretty comprehensive list of useful frameworks here.

      All the code we’ve written can be found here.

      Grundlegendes zu Vue.js Lifecycle Hooks


      Einführung

      Lifecycle Hooks bieten einen Einblick in die Funktionsweise der von Ihnen verwendeten Bibliothek hinter den Kulissen. Mithilfe von Lifecycle Hooks können Sie feststellen, wann Ihre Komponente erstellt, dem DOM hinzugefügt, aktualisiert oder zerstört wird.

      Dieses Diagramm aus der offiziellen Vue.js-Dokumentation erfasst den Vue.js Instance-Lifecycle:

      Vue.js Instance-Lifecycle-Diagramm ansehen

      Dieser Artikel führt Sie in die Erstellung, Montage, Aktualisierung und Zerstörung von Hooks ein.

      Grundlegendes zu Creation Hooks (Initialisierung)

      Creation Hooks sind die allerersten Hooks, die in Ihrer Komponente ausgeführt werden. Mit ihnen können Sie Aktionen ausführen, bevor Ihre Komponente überhaupt zum DOM hinzugefügt wurde. Im Gegensatz zu allen anderen Hooks werden Creation Hooks auch beim serverseitigen Rendern ausgeführt.

      Verwenden Sie Creation Hooks, wenn Sie Dinge in Ihrer Komponente einrichten müssen, sowohl beim Client-Rendering als auch beim Server-Rendering.

      Sie haben keinen Zugriff auf DOM oder das Zielmontageelement (this.$el) innerhalb der Creation Hooks.

      beforeCreate

      Der beforeCreate Hook wird bei der Initialisierung Ihrer Komponente ausgeführt. Daten wurden nicht reaktiv gemacht und Ereignisse wurden noch nicht eingerichtet:

      ExampleComponent.vue

      <script>
      export default {
        beforeCreate() {
          console.log('At this point, events and lifecycle have been initialized.')
        }
      }
      </script>
      

      In diesem Beispiel protokolliert dieser Snippet die Nachricht, wenn der beforeCreate-Hook ausgeführt wird: Zu diesem Zeitpunkt werden Ereignisse und Lebenszyklus initialisiert.

      erstellt

      Sie können auf reaktive Daten und Ereignisse zugreifen, die mit dem erstellten Hook aktiv sind. Vorlagen und Virtual DOM wurden noch nicht montiert oder zurückgegeben:

      ExampleComponent.vue

      <template>
        <div ref="example-element">{{ propertyComputed }}</div>
      </template>
      
      <script>
      export default {
        data() {
          return {
            property: 'Example property.'
          }
        },
      
        computed: {
          propertyComputed() {
            return this.property
          }
        },
      
        created() {
          console.log('At this point, this.property is now reactive and propertyComputed will update.')
          this.property = 'Example property updated.'
        }
      }
      </script>
      

      In diesem Beispiel speichert der Snippet Eigenschaft als Beispieleigenschaft. Wenn der erstellte Hook ausgeführt wird, wird eine Nachricht von An diesem Punkt ist diese.Eigenschaft nun reaktiv und propertyComputed wird aktualisiert, protokolliert. Und dann wird die Eigenschaft in Beispieleigenschaft aktualisiert geändert.

      Später im Lebenszyklus wird {{ propertyComputed }} als Beispieleigenschaft aktualisiert anstelle von Beispieleigenschaft angezeigt.

      In diesem Schritt haben Sie einige Beispiele für Creation Hooks überprüft und sind bereit, zum nächsten Teil des Lebenszyklus zu wechseln, die Mounting Hooks.

      Grundlegendes zu Mounting Hooks (DOM-Eingabe)

      Mounting Hooks sind die am häufigsten verwendeten Hooks. Sie ermöglichen es Ihnen, sofort vor und nach dem ersten Rendern auf Ihre Komponente zuzugreifen. Sie werden jedoch nicht während des serverseitigen Renderings ausgeführt.

      Verwenden Sie Mounting Hooks, wenn Sie auf das DOM Ihrer Komponente sofort vor oder nach dem ersten Rendern zugreifen oder es ändern müssen.

      Verwenden Sie keine Mounting Hooks, wenn Sie Daten für Ihre Komponente bei der Initialisierung abrufen müssen.

      Hinweis: Verwenden Sie stattdessen erstellt (oder erstellt und aktiviert für Komponenten, die am Leben gehalten werden sollen). Besonders, wenn Sie diese Daten während des serverseitigen Renderings benötigen.

      beforeMount

      Der beforeMount Hook wird direkt vor dem ersten Rendering ausgeführt und nachdem die Vorlage oder Renderfunktionen kompiliert wurden:

      ExampleComponent.vue

      <script>
      export default {
        beforeMount() {
          console.log(`At this point, vm.$el has not been created yet.`)
        }
      }
      </script>
      

      In diesem Beispiel protokolliert dieser Snippet bei der Ausführung des beforeMount Hook die Nachricht: Zu diesem Zeitpunkt wurde vm.$el noch nicht erstellt.

      montiert

      Im montierten Hook haben Sie vollen Zugriff auf die reaktive Komponente, die Vorlagen und das zurückgegebene DOM (über this.$el).

      Verwenden Sie zur Änderung des DOM montiert – insbesondere bei der Integration von nicht-Vue-Bibliotheken:

      ExampleComponent.vue

      <template>
        <div ref="example-element">Example component.</div>
      </template>
      
      <script>
      export default {
        mounted() {
          console.log(`At this point, vm.$el has been created and el has been replaced.`);
          console.log(this.$el.textContent) // Example component.
        }
      }
      </script>
      

      In diesem Beispiel protokolliert dieser Snippet die Nachricht, wenn der montierte Hook ausgeführt wird Zu diesem Zeitpunkt wurde vm.$el erstellt und el ersetzt. Außerdem wird eine Nachricht von Beispielinhalt. (this.$el.textContent) protokolliert.

      In diesem Abschnitt haben Sie Anwendungsfälle für Mounting Hooks erkundet. Im nächsten Schritt überprüfen Sie einige Beispiele, die Updating Hooks verwenden.

      Grundlegendes zu Updating Hooks (Diff & Re-render)

      Updating Hooks werden aufgerufen, wenn eine reaktive Eigenschaft, die von Ihrer Komponente verwendet wird, sich ändert oder etwas anderes ein erneutes Rendering verursacht. Sie ermöglichen es Ihnen, den Zyklus watch-compute-render für Ihre Komponente zu haken.

      Verwenden Sie Updating Hooks, wenn Sie wissen müssen, wann Ihre Komponente neu gerendert wird, z. B. für das Debuggen oder das Profiling.

      Verwenden Sie die Updating Hooks nicht, wenn Sie wissen müssen, wann sich eine reaktive Eigenschaft auf Ihrer Komponente ändert. Verwenden Sie stattdessen computed Eigenschaften oder Watchers.

      beforeUpdate

      Der beforeUpdate Hook wird nach Datenänderungen Ihrer Komponente ausgeführt und der Update-Zyklus beginnt, unmittelbar bevor das DOM gepatcht und neu gerendert wird.

      Verwenden Sie beforeUpdate, wenn Sie den neuen Status aller reaktiven Daten auf Ihrer Komponente erhalten müssen, bevor sie tatsächlich zurückgegeben wird:

      ExampleComponent.vue

      <template>
        <div ref="example-element">{{counter}}</div>
      </template>
      
      <script>
      export default {
        data() {
          return {
            counter: 0
          }
        },
      
        created() {
          setInterval(() => {
            this.counter++
          }, 1000)
        },
      
        beforeUpdate() {
          console.log(`At this point, Virtual DOM has not re-rendered or patched yet.`)
          // Logs the counter value every second, before the DOM updates.
          console.log(this.counter)
        }
      }
      </script>
      

      Zuerst speichert dieser Snippet Zähler als 0. Wenn der erstellte Hook ausgeführt wird, wird er den Zähler alle 1000 ms erhöhen. Wenn der beforeUpdate-Hook ausgeführt wird, protokolliert dieses Snippet die Nachricht: Zu diesem Zeitpunkt hat Virtual DOM noch nicht neu gerendert oder gepatcht. Eine Zahl für Zähler wird protokolliert.

      aktualisiert

      Der aktualisierte Hook wird nach Datenänderungen Ihrer Komponente und den Neu-Renderings des DOM ausgeführt.

      Verwenden Sie aktualisiert, wenn Sie nach einer Eigenschaftsänderung auf DOM zugreifen müssen:

      ExampleComponent.vue

      <template>
        <div ref="example-element">{{counter}}</div>
      </template>
      
      <script>
      export default {
        data() {
          return {
            counter: 0
          }
        },
      
        created() {
          setInterval(() => {
            this.counter++
          }, 1000)
        },
      
        updated() {
          console.log(`At this point, Virtual DOM has re-rendered and patched.`)
          // Fired every second, should always be true
          console.log(+this.$refs['example-element'].textContent === this.counter)
        }
      }
      </script>
      

      Zuerst speichert dieser Snippet Zähler als 0. Wenn der erstellte Hook ausgeführt wird, wird er den Zähler alle 1000 ms erhöhen. Wenn der aktualisierte Hook ausgeführt wird, protokolliert dieses Snippet die Nachricht: Zu diesem Zeitpunkt hat Virtual DOM erneut gerendert und gepatcht. und ein boolescher Wert von wahr wird protokolliert, da der gerenderte Wert und der aktuelle Wert gleich sind.

      Nachdem Sie nun die Verwendung der Updating Hooks kennengelernt haben, sind Sie bereit, mehr über Destruction Hooks zu erfahren.

      Grundlegendes zu Destruction Hooks (Teardown)

      Destruction Hooks ermöglichen Ihnen, Aktionen durchzuführen, wenn Ihre Komponente zerstört wird, wie das Übergeben von Analysen und Bereinigungen. Sie werden abgegeben, wenn Ihre Komponente zerstört und aus DOM entfernt wird.

      beforeDestroy

      beforeDestroy wird direkt vor dem Löschen abgegeben. Ihre Komponente wird immer noch vollständig vorhanden und funktionell sein.

      Verwenden Sie beforeDestroy, wenn Sie Ereignisse oder reaktive Abonnements löschen müssen:

      ExampleComponent.vue

      <script>
      export default {
        data() {
          return {
            exampleLeakyProperty: 'This represents a property that will leak memory if not cleaned up.'
          }
        },
      
        beforeDestroy() {
          console.log(`At this point, watchers, child components, and event listeners have not been teared down yet.`)
          // Perform the teardown procedure for exampleLeakyProperty.
          // (In this case, effectively nothing)
          this.exampleLeakyProperty = null
          delete this.exampleLeakyProperty
        }
      }
      </script>
      

      Dieses Snippet speichert zunächst exampleLeakyProperty. Wenn der beforeDestroy Hook ausgeführt wird, protokolliert dieser Snippet die Nachricht An diesem Punkt wurden Watchers, untergeordnete Komponenten und Ereignis-Listener noch nicht zerstört. und dann exampleLeakyProperty gelöscht.

      zerstört

      Bis zu den zerstörten Hook erreichen, ist praktisch nichts mehr in Ihrer Komponente. Alles, was daran hing, wurde zerstört.

      Verwenden Sie zerstört, wenn Sie eine Last-Minute-Bereinigung ausführen oder einen Remote-Server darüber informieren müssen, dass die Komponente zerstört wurde:

      ExampleComponent.vue

      <script>
      import ExampleAnalyticsService from './example-analytics-service'
      
      export default {
        destroyed() {
          console.log(`At this point, watchers, child components, and event listeners have been torn down.`)
          console.log(this)
          ExampleAnalyticsService.informService('Component destroyed.')
        }
      }
      </script>
      

      Zuerst importiert dieser Snippet ExampleAnalyticsService. Wenn der beforeDestroy Hook ausgeführt wird, protokolliert dieser Snippet die Nachricht An diesem Punkt wurden Watchers, untergeordnete Komponenten und Ereignis-Listener zerstört. Was von der Komponente übrig bleibt, wird in die Konsole protokolliert und ExampleAnalyticsService wird an die Nachricht Komponente zerstört übergeben.

      Damit haben Sie Ihre allgemeine Überprüfung der Vue.js Lifecycle Hooks abgeschlossen.

      Andere Hooks

      Es gibt zwei weitere Hooks, aktiviert und deaktiviert. Diese sind für keep-alive Komponenten, ein Thema, das außerhalb des Geltungsbereichs dieses Artikels liegt.

      Es genügt zu sagen, dass sie es Ihnen ermöglichen, zu erkennen, wenn eine Komponente, die in einem Tag <keep-alive></keep-alive> eingegeben wird, ein- oder ausgeschaltet wird. Vielleicht verwenden Sie sie, um Daten für Ihre Komponente abzurufen oder Statusänderungen zu verarbeiten, wobei sie sich als erstellt und beforeDestroy effektiv verhalten, ohne dass eine vollständige Neuerstellung der Komponente erforderlich ist.

      Zusammenfassung

      In diesem Artikel wurden Ihnen verschiedene Lifecycle Hooks vorgestellt, die im Vue.js Instance Lifecycle verfügbar sind. Sie haben die verschiedenen Anwendungsfälle für die Erstellung von Hooks, die Montage von Hooks, die Aktualisierung von Hooks und die Zerstörung von Hooks erkundet.

      Wenn Sie mehr über Vue.js erfahren möchten, lesen Sie unsere Themenseite zu Vue.js für Übungen und Programmierprojekte.



      Source link

      Comprendre les hooks de cycle de vie Vue.js


      Introduction

      Les hooks de cycle de vie apparaissent sous la forme d’une fenêtre dans laquelle vous pouvez voir de quelle manière la bibliothèque que vous utilisez fonctionne en arrière-plan. Ils vous permettent de savoir à quel moment votre composant est créé, ajouté au DOM, mis à jour ou détruit.

      Ce schéma, tiré de la documentation officielle de Vue.js, représente le cycle de vie de l’instance Vue.js :

      Schéma du cycle de vie de Vue.js

      Cet article est une introduction aux hooks de création, de compilation, de mise à jour et de destruction.

      Comprendre les hooks de création (initialisation)

      Les hooks de création sont les tous premiers à s’exécuter dans votre composant. Ils vous permettent de réaliser des actions avant même que votre composant n’ait été ajouté au DOM. Contrairement aux autres, les hooks de création sont également exécutés lorsque le rendu est généré côté serveur.

      Vous pouvez les utiliser pour configurer certains éléments dans votre composant, que le rendu soit généré côté client ou côté serveur.

      À l’intérieur des hooks de création, vous n’aurez pas accès au DOM ou à l’élément de compilation cible (this.$el).

      beforeCreate

      Le hook beforeCreate s’exécute au moment même de l’initalisation de votre composant. data n’a pas été activé et les events n’ont pas encore été configurés :

      ExampleComponent.vue

      <script>
      export default {
        beforeCreate() {
          console.log('At this point, events and lifecycle have been initialized.')
        }
      }
      </script>
      

      Dans cet exemple, lorsque le hook beforeCreate est exécuté, ce fragment de code consigne le message suivant : Initialisation des événements et du cycle de vie.

      created

      Le hook created vous permet d’accéder aux data et events qui sont actifs. La compilation ou le rendu des modèles et du DOM virtuel n’ont pas encore été déclenchés :

      ExampleComponent.vue

      <template>
        <div ref="example-element">{{ propertyComputed }}</div>
      </template>
      
      <script>
      export default {
        data() {
          return {
            property: 'Example property.'
          }
        },
      
        computed: {
          propertyComputed() {
            return this.property
          }
        },
      
        created() {
          console.log('At this point, this.property is now reactive and propertyComputed will update.')
          this.property = 'Example property updated.'
        }
      }
      </script>
      

      Dans cet exemple, le fragment de code consigne que property est une Example property. Lorsque le hook created est exécuté, le message suivant est enregistré : this.property est maintenant réactive et propertyComputed sera mise à jour. Ensuite, la valeur sous property est remplacée par Example property updated.

      Plus tard dans le cycle de vie, {{propertyComputed }} indiquera Example property updated au lieu de Example property.

      Au cours de cette étape, vous avez examiné quelques exemples de hooks de création. Vous êtes maintenant prêt à passer à la prochaine étape du cycle de vie, la compilation de hooks.

      Comprendre les hooks de compilation (insertion DOM)

      Les hooks de compilation sont ceux qui sont généralement les plus utilisés. Ils vous permettent d’accéder à votre composant immédiatement avant et après avoir généré le premier rendu. Cependant, ils ne sont pas exécutés lors du rendu côté serveur.

      Vous pouvez utiliser les hooks de compilation pour accéder ou modifier le DOM de votre composant immédiatement avant ou après avoir généré le rendu initial.

      N’utilisez pas de hooks de compilation pour récupérer des données sur votre composant lors de son initialisation.

      Remarque : pour cela, utilisez plutôt created (ou created et activated pour les composants keep-alive), surtout si vous avez besoin de ces données pour le rendu côté serveur.

      beforeMount

      Le hook beforeMount s’exécute juste avant l’occurrence du rendu initial et une fois que les fonctions du modèle ou du rendu aient été compilées :

      ExampleComponent.vue

      <script>
      export default {
        beforeMount() {
          console.log(`At this point, vm.$el has not been created yet.`)
        }
      }
      </script>
      

      Dans cet exemple, lorsque le hook beforeMount est exécuté, ce fragment de code enregistrera le message suivant : vm.$el n'a pas encore été créé.

      mounted

      Le hook mounted vous permet d’avoir un total accès au composant réactif, aux modèles et au DOM rendu (via this.$el).

      Utilisez mounted pour modifier le DOM, notamment lors de l’intégration de bibliothèque hors Vue :

      ExampleComponent.vue

      <template>
        <div ref="example-element">Example component.</div>
      </template>
      
      <script>
      export default {
        mounted() {
          console.log(`At this point, vm.$el has been created and el has been replaced.`);
          console.log(this.$el.textContent) // Example component.
        }
      }
      </script>
      

      Dans notre exemple, lorsque le hook mounted est exécuté, ce fragment de code consigne le message suivant : Crée vm.$el pour remplacer el. Le message Ceci est un exemple de texte (this.$el.textContent) sera également enregistré.

      Au cours de cette section, vous avez exploré les cas d’utilisation de hooks de compilation. À l’étape suivante, vous allez aborder quelques exemples de hooks de mise à jour.

      Comprendre les hooks de mise à jour (Diff et Re-render)

      Les Updating hooks se déclenchnt à chaque fois qu’une propriété réactive utilisée par votre composant change ou que quelque chose d’autre vous pousse à le re-render. Ils vous permettent de vous hooker au cycle watch-compute-render de votre composant.

      Vous pouvez utiliser les hooks de mise à jour pour savoir à quel moment le rendu du composant est de nouveau déclenché, éventuellement en vue d’un débogage ou d’un profilage.

      N’utilisez pas la mise à jour de hooks pour déterminer à quel moment une propriété réactive de votre composant change. Utilisez plutôt computed properties ou watchers.

      beforeUpdate

      Le hook beforeUpdate s’exécute une fois que les données de votre composant changent et que le cycle de mise à jour commence, juste avant que le DOM n’ait été patché et n’ait généré un re-render.

      Utilisez beforeUpdate pour consulter le nouvel état de toute donnée réactive de votre composant avant que le rendu soit effectivement généré :

      ExampleComponent.vue

      <template>
        <div ref="example-element">{{counter}}</div>
      </template>
      
      <script>
      export default {
        data() {
          return {
            counter: 0
          }
        },
      
        created() {
          setInterval(() => {
            this.counter++
          }, 1000)
        },
      
        beforeUpdate() {
          console.log(`At this point, Virtual DOM has not re-rendered or patched yet.`)
          // Logs the counter value every second, before the DOM updates.
          console.log(this.counter)
        }
      }
      </script>
      

      Tout d’abord, sous counter, ce fragment de code enregistrera 0. Lorsque le hook created est exécuté, la valeur du counter incrémentera toutes les 1 000 ms. Lorsque le hook beforeUpdate est exécuté, ce fragment de code enregistrera le message suivant : DOM virtuel pas encore été rendu ou patché. et un numéro sera enregistré sous counter.

      updated

      L’exécution du hook updated se fait à chaque fois que les données concernant votre composant sont modifiées et que le DOM déclenche un re-render.

      Utilisez updated pour accéder au DOM une fois qu’une propriété ait été modifiée :

      ExampleComponent.vue

      <template>
        <div ref="example-element">{{counter}}</div>
      </template>
      
      <script>
      export default {
        data() {
          return {
            counter: 0
          }
        },
      
        created() {
          setInterval(() => {
            this.counter++
          }, 1000)
        },
      
        updated() {
          console.log(`At this point, Virtual DOM has re-rendered and patched.`)
          // Fired every second, should always be true
          console.log(+this.$refs['example-element'].textContent === this.counter)
        }
      }
      </script>
      

      Tout d’abord, sous counter, ce fragment de code enregistrera 0. Lorsque le hook created est exécuté, la valeur du counter incrémentera toutes les 1 000 ms. Lorsque le hook updated est exécuté, ce fragment de code consigne le message suivant : Nouveau rendu et patch du DOM virtuel. Et, étant donné que la valeur du rendu est égale à la valeur actuelle, la valeur booléenne de true est consignée.

      Maintenant que vous en savez davantage sur l’utilisation des hooks de mise à jour, nous pouvons aborder les hooks de destruction.

      Comprendre les hooks de destruction (Démontage)

      Les hooks de destruction vous permettent d’effectuer des actions lorsque votre composant est détruit. Vous pouvez par exemple procéder à son nettoyage ou à l’envoi d’analyses. Ils se déclenchent au moment où votre composant est détruit et supprimé du DOM.

      beforeDestroy

      Le déclenchement de beforeDestroy se fait juste avant le démontage. Votre composant sera toujours présent et totalement fonctionnel.

      Utilisez beforeDestroy pour nettoyer des événements ou des abonnements réactifs :

      ExampleComponent.vue

      <script>
      export default {
        data() {
          return {
            exampleLeakyProperty: 'This represents a property that will leak memory if not cleaned up.'
          }
        },
      
        beforeDestroy() {
          console.log(`At this point, watchers, child components, and event listeners have not been teared down yet.`)
          // Perform the teardown procedure for exampleLeakyProperty.
          // (In this case, effectively nothing)
          this.exampleLeakyProperty = null
          delete this.exampleLeakyProperty
        }
      }
      </script>
      

      Ce fragment de code consignera tout d’abord exampleLeakyProperty. Lorsque le hook beforeDestroy est exécuté, ce fragment de code enregistrera le message suivant : Les observateurs, composants enfants et écouteurs d'événements n'ont pas encore été éliminés. Ensuite, exampleLeakyProperty est supprimé.

      destroyed

      Une fois que vous aurez atteint votre hooker destroyed, il ne vous restera pratiquement plus rien à faire sur votre composant. Tout ce qui y était rattaché a été détruit.

      Utilisez destroyed pour procéder à un nettoyage de dernière minute ou signaler à un serveur distant que le composant a été détruit :

      ExampleComponent.vue

      <script>
      import ExampleAnalyticsService from './example-analytics-service'
      
      export default {
        destroyed() {
          console.log(`At this point, watchers, child components, and event listeners have been torn down.`)
          console.log(this)
          ExampleAnalyticsService.informService('Component destroyed.')
        }
      }
      </script>
      

      Dans un premier temps, ce fragment de code importera ExampleAnalyticsService. Lorsque le hook beforeDestroy est exécuté, ce fragment de code consignera le message suivant : Supprime les observateurs, composants enfant et écouteurs d'événements. Ce qui reste du composant sera consigné dans la console et ExampleAnalyticsService transmettra le message suivant :Détruit.

      Voilà, vous êtes arrivé à la fin votre révision générale sur les hooks de cycle de vie Vue.js.

      Autres hooks

      Il existe deux autres hooks : activated et deactivated. Ils sont dédiés aux composants keep-alive, un sujet qui n’entre pas dans le cadre de cet article.

      Il vous suffit de savoir qu’ils vous permettent de détecter à quel moment un composant enveloppé dans une balise <keep-alive></keep-alive> est activé ou désactivé. Vous pouvez les utiliser pour récupérer les données de votre composant ou gérer les changements d’état, car ils se comportent effectivement comme created et beforeDestroy sans avoir à reconstruire un composant dans son intégralité.

      Conclusion

      Dans cet article, vous avez abordé les différents hooks de cycle de vie disponibles dans le cycle de vie d’une instance Vue.js. Vous avez découvert différents cas d’utilisation de hooks de création, de compilation, de mise à jour et de destruction.

      Si vous souhaitez en savoir plus sur Vue.js, veuillez consulter notre page thématique Vue.js dans laquelle vous trouverez des exercices et des projets de programmation.



      Source link