# vuex Published articles for vuex. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Post-Mortem: Outbreak Database DevFeed: [Post-Mortem: Outbreak Database]() Original publisher: [Read original article]() Author: andrew@nystudio107.com (Andrew Welch) Published: 2020-03-03T05:00:00Z Content type: article Language: en Sources: [nystudio107 | Articles on modern web development.]() Topics: [migration](), [Content Management System](), [PHP](), [Front end](), [Vue.js](), [GraphQL](), [axios](), [Website](), [Back end](), [API]() Tags: [aging](), [axios](), [cms](), [content](), [craft](), [custom](), [frontend](), [graphql](), [hybrid](), [management](), [migration](), [modernizing](), [php](), [post-mortem](), [post-mortems](), [twig-vue-js](), [vue](), [vuex](), [website]() ### AI overview A post-mortem on modernizing the aging custom PHP Outbreak Database website by migrating it to Craft CMS and planning a hybrid Twig/Vue.js frontend using Vuex, Axios, and GraphQL. The project aimed to improve content maintenance, researcher and journalist usability, and long-term technical foundations. ### Source excerpt Modernizing an aging custom PHP website with Craft CMS for content management, and a hybrid Twig/Vue.js + Vuex + Axios + GraphQL on the frontend ## Vue.js Advanced Reactivity API and Caching Method-style Getters DevFeed: [Vue.js Advanced Reactivity API and Caching Method-style Getters]() Original publisher: [Read original article]() Author: Michael Gallagher Published: 2019-07-11T11:48:14Z Content type: tutorial Language: en Sources: [Teamwork]() Topics: [Caching](), [Vue.js](), [reactive](), [Code]() Tags: [advanced](), [caching](), [code](), [front-end-development](), [javascript](), [js](), [performance](), [vue](), [vue-js](), [vuejs](), [vuex]() ### AI overview This tutorial explains why Vuex method-style getter invocations do not cache their returned values, distinguishes that behavior from property-style getter caching, and discusses how to implement result caching when performance measurements justify it. It also relates the approach to Vue's Advanced Reactivity API and method-style computed properties. ### Source excerpt We're going to talk about a common request when working with relational data in Vuex. Why and how to cache method-style getter invocations, though the principles would also apply to method-style computed properties. If you have been following recent Vue v3 RFCs, you might have come across the Advanced Reactivity API, which comes as a very welcome direction for Vue to take. This article is written using Vue v2, but ultimately the code will be simplified if this RFC is implemented. Firstly, although both property-style and method-style getters offer caching as part of core Vuex functionality, method-style getter invocations do not cache results. If that doesn't make much sense, keep reading, it should become clear. What is a Method-style Getter? Below is the example from the Vuex documentation of a method-style getter, sometimes referred to as a parameterized getter. getTodoById: (state) => (id) => { return state.todos.find(todo => todo.id === id) } Normally a getter works by processing state into a given result. todoCount: (state) => state.todos.length, This will mean that store.getters.todoCount might provide the value 12, which will be cached in the event that the value is accessed again without any underlying reactive data changing. isTodoOpen: (state) => (id) => !!state.todos[id].assignee && state.todos[id].status !== 'complete', The above example can be accessed by store.getters.isTodoOpen(123) which will return a boolean. This value is not cached, calling it repeatedly will result in multiple executions. So what is cached here? Nothing from a reactive standpoint. When the getter property is accessed on the store, store.getters.isTodoOpen, just prior to invocation, this will run the outer function which will not access any reactive data, but create a function, an arrow which accepts id. This created function is now cached. Why aren't the results of these getters cached? There are lots of good reasons not to cache the results of these functions. How many times wo ## Embedding Teamwork Chat DevFeed: [Embedding Teamwork Chat]() Original publisher: [Read original article]() Author: Dawid Myslak Published: 2017-10-23T15:52:56Z Content type: article Language: en Sources: [Teamwork]() Topics: [Vue.js](), [Front end](), [JavaScript](), [Web Development](), [Webpack](), [Development](), [Framework](), [Library](), [flux](), [ESLint](), [Node.js]() Tags: [chat](), [development](), [eslint](), [flux](), [implementation](), [javascript](), [vuejs](), [vuex](), [webpack]() ### AI overview The article describes how Teamwork.com embedded Teamwork Chat Project Rooms directly in Teamwork Projects. The team chose a new component-based implementation and used Vue.js, Vuex, Webpack, modern JavaScript, ESLint, and reusable Node.js modules while considering performance. ### Source excerpt A couple of weeks ago we introduced a new feature in Teamwork Chat called Project Rooms. Project Rooms are a great way to create dedicated real-time communication channels for specific projects. Our next priority was to take this feature even further. Project Rooms in Teamwork Chat.Embedded Teamwork Chat Currently Project Rooms can be used inside Teamwork Chat, but our goal was to make them accessible directly in Teamwork Projects. To achieve this, we considered the following two options: Decouple only the important bits and pieces from the existing codebase of Teamwork Chat and deliver them as a standalone module. Create a brand new solution that follows component based architecture which could potentially be the future core codebase for the next generation of Teamwork Chat. After looking into this for a while, we decided that the second option will let us deliver a better quality solution. Our main concern with decoupling the existing codebase was the fact that we didn't use a component based architecture in the existing client. Unfortunately at the time of the initial implementation of the app, Knockout.js components weren't a common choice. New tech stack Earlier this year at Teamwork.com we made the decision that all our development teams will start using Vue.js as the main front-end framework. We also started working on creating a new internal build system based on Webpack, which allows us to use the latest front-end tools and makes the development process significantly more productive. Together with Vue.js we started using Vuex, which is a state management library inspired by Flux architecture. Another big change for us was dropping CoffeeScript and replacing it with the next generation of JavaScript. JavaScript ES2015+ comes with great new features and syntax, but also offers incredible editor support and great ESLint that makes our code more consistent across the team. New technology stack for embedded Teamwork Chat. Luckily, during the development of an ex