Next.js Cheat Sheet | Page Rendering with Next.js

This is the easiest and most complete cheat sheet to quickly understand how Next.js page rendering strategies works. Moreover, this unique cheat sheet clearly reveals how each strategy influences the Core Web Vitals signals: TTFB, FP, FCP, LCP, TBT and TTI.

Next.js uses 4 rendering strategies to build, deliver and render a React Single Page App (SPA):

Static-Site Generation (SSG)
Server-Side Rendering (SSR)
Incremental Static Regeneration (ISR)
Client-Side Rendering (CSR)

Detailed explanations are also included to help you choose the right page rendering strategy for all use cases and thus create speedy Web applications that Google and visitors love.

Enjoy!

Next.js: The Ultimate Cheat Sheet to Page Rendering [Infographic]

How to use

The 4 page rendering strategies are identified with their respective acronym (SSG, SSR, ISR and CSR) and laid out in columns besides each other in the middle of the infographic.

Completely on the left side of these 4 columns you’ll find the 6 steps involved during the processing flow from the build step on the server side up to the client-side rendering.

Completely on the right side of these 4 columns you’ll find where each step happens in the processing flow which is either server side or client side.

For each strategy column you’ll see where and when a build action (page generation) is executed in the step. You’ll also see the generated content flow (HTML - React/CSS/JS/Data) during each single step.

Core Web Vitals

The Core Web Vitals (CWV), parts of the new page experience ranking factor from Google, are identified using 3 distinctive background colors, each related to the performance impact on the CWV.

A red color means POOR performance results, an orange color means GOOD performance while a green color means the BEST performance.

Live Demo

You’ll find a live demo with example source code on Github for testing the performance of each page rendering strategies discussed in the cheat sheet:
https://next-page-rendering.vercel.app/

Static-Site Generation (SSG)

Static-Site Generation (SSG) is the default strategy offered by Next.js to generate web pages. Next.js recommends this strategy to get the best performance results as static content is distributed faster using CDNs which are closer to your visitors and thus leading to a faster Time to First Byte (TTFB).

Steps description

STEP 1: Next.js generates a Single Page App in an .html file along with the .css and .js on the server. This step called pre-rendering is done only once at build time when you run the next build command. That is usually done when you deploy your application. This is during this step that all the page coding (HTML) is generated including the React code, CSS, JavaScript and optionally the data if the page is using any data fetching method such as getStaticProps() or getStaticPaths().

STEP 2: The client requests the Single Page App from the CDN.

STEP 3: The client downloads the Single Page App from the CDN.

STEP 4: The client parses and renders the Single Page App into the browser. This is where the 3 Core Web Vitals signals (First Paint, First Contentful Paint and Largest Contentful Paint) are fired. Because the HTML of the page has been pre-rendered on the server side, the client browser just has to load and render it as is. And because the page is coded in a way that allows the browser to render it with minimum JavaScript code, render-blocking is reduced to its minimum leading to good performance results.

STEP 5: The React (JavaScript) code is run to (re)Hydrate the page. Even though the page has been pre-built, this extra step is required to allow React to attach or activate the JavaScript events to its Virtual DOM and make the page interactive. Because JavaScript is run at this point, Total Blocking Time is affected by this extra step. Also, because the browser has to wait for the hydration process to complete, Time To Interactive is also affected.

Here is the complete Typescript code of a web page that uses Next.js' Static-Site Generation strategy (SSG):

// Next.js libraries
import Head from 'next/head'

// Custom Components
import BackToHome from 'components/BackToHome'

// Page component
export default function StaticSideGeneration({ jsonData }) {
  return (
    <>
      <Head>
        <title>Static-Site Generation (SSG) • Guy Dumais</title>
        <meta name="description" content="Example page using Static-Site Generation (SSG) with Next.js 11 and React 17"/>
        <meta name="viewport" content="initial-scale=1.0, width=device-width" />
      </Head>
      <BackToHome/>
      <h1>Static-Site Generation (SSG)</h1>
      <p>Data fetched at build-time on the server-side before sending to the client.</p>
      <ul>
      {
        jsonData.data.map((e) => (
          <li key={e.id}>{e.email}</li>
        ))
      }
      </ul>
    </>
  )
}

// This function gets called at build time on server-side.
// It won't be called on client-side, so you can even do
// direct database queries.
export async function getStaticProps() {
  const res = await fetch('https://reqres.in/api/users?page=2')
  const jsonData = await res.json()

  return {
    props: {
      jsonData, // will be passed to the page component as props
    },
  }
}

Server Side Rendering (SSR)

Server Side Rendering (SSR) is the second strategy offered by Next.js to generate web pages. Next.js recommends to avoid using this strategy as much as possible to get the best performance results as the static content is built (pre-rendered) and distributed per-request only. Because of the extra time required by the build process, the Time to First Byte (TTFB) signal is increased and leads to poor results.

Steps description

STEP 1: Next.js does not generate (pre-render) any page.

STEP 2: The client requests the Single Page App from the server. Next.js generates (pre-render) a Single Page App in an .html file along with the .css and .js on the server. This is during this step that all the page coding (HTML) is generated including the React code, CSS, JavaScript and optionally the data if the page is using the getServerSideProps() data fetching method.

STEP 3: The client downloads the Single Page App from the server.

STEP 4: Same as STEP 4 in SSG.

STEP 5: Same as STEP 5 in SSG.

Here is the complete Typescript code of a web page that uses Next.js' Server Side Rendering strategy (SSR):

// Next.js libraries
import Head from 'next/head'

// Custom Components
import BackToHome from 'components/BackToHome'

// Page component
export default function ServerSideRendering({ jsonData }) {
  return (
    <>
      <Head>
        <title>Server-Side Rendering (SSR) • Guy Dumais</title>
        <meta name="description" content="Example page using Server-Side Rendering (SSR) with Next.js 11 and React 17"/>
        <meta name="viewport" content="initial-scale=1.0, width=device-width" />
      </Head>
      <BackToHome/>
      <h1>Server-Side Rendering (SSR)</h1>
      <p>Data fetched on the server-side at <b>each</b> request before sending to the client.</p>
      <ul>
      {
        jsonData.data.map((e) => (
          <li key={e.id}>{e.email}</li>
        ))
      }
      </ul>
    </>
  )
}

export async function getServerSideProps() {
  const res = await fetch('https://reqres.in/api/users?page=2')
  const jsonData = await res.json()

  return {
    props: {
      jsonData, // will be passed to the page component as props
    },
  }
}

Incremental Static Regeneration (ISR)

Incremental Static Regeneration (ISR) is the third strategy offered by Next.js to generate web pages. It is the same as Static Site Generation except that content can be rebuilt when the page is updated.

Steps description

STEP 1: Same as STEP 1 in SSG.

STEP 2: The client requests the Single Page App from the CDN. Also, if the page is using the data fetching method getStaticProps() combined with the revalidate option, then the page is regenerated if the data returned from the fetching results has been updated. Next.js recommends using this method for a huge site having over 1,000 pages. Because pre-rendering each page takes time, using this incremental method will pre-render on the first request and when the page content is updated only.

STEP 3: Same as STEP 3 in SSG.

STEP 4: Same as STEP 4 in SSG.

STEP 5: Same as STEP 5 in SSG.

Here is the complete Typescript code of a web page that uses Next.js' Incremental Static Regeneration strategy (ISR):

// Next.js libraries
import Head from 'next/head'

// Custom Components
import BackToHome from 'components/BackToHome'

// Page component
export default function IncrementalStaticGeneration({ jsonData }) {
  return (
    <>
      <Head>
        <title>Incremental Static Regeneration (ISR) • Guy Dumais</title>
        <meta name="description" content="Example page using Incremental Static Regeneration (ISR) with Next.js 11 and React 17"/>
        <meta name="viewport" content="initial-scale=1.0, width=device-width" />
      </Head>
      <BackToHome/>
      <h1>Incremental Static Regeneration (ISR)</h1>
      <p>Data fetched at build-time on the server-side and rebuilt when data updated.</p>
      <ul>
      {
        jsonData.data.map((e) => (
        <li key={e.id}>{e.email}</li>
      ))
      }
      </ul>
    </>
  )
}

// This function gets called at build time on server-side.
// It may be called again, on a serverless function, if
// revalidation is enabled and a new request comes in
export async function getStaticProps() {
  const res = await fetch('https://reqres.in/api/users?page=2')
  const jsonData = await res.json()

  return {
    props: {
      jsonData, // will be passed to the page component as props
    },

    // Next.js will attempt to re-generate the page:
    // - When a request comes in
    // - At most once every second
    revalidate: 100, // In seconds
  }
}

Client Side Rendering (CSR)

Client Side Rendering (CSR) is the fourth strategy offered by Next.js to generate web pages. It is the same as Static Site Generation except that parts of the content can be built on the client side.

Steps description

STEP 1: Same as STEP 1 in SSG except that the content (data) is not pre-rendered nor included in the static bunch. Which results in a smaller file size thus leading to shorter download time.

STEP 2: Same as STEP 2 in SSG but without content (data).

STEP 3: Same as STEP 3 in SSG but without content (data).

STEP 4: Same as STEP 4 in SSG.

STEP 5: Same as STEP 5 in SSG but without content (data).

STEP 6: The client fetches the content (data) and React updates the UI. This method is useful, for example, when you want to show up a skeleton page with static content and then progressively inject the data in a page requiring a long wait time for data fetching.

Here is the complete Typescript code of a web page that uses Next.js' Client Side Rendering strategy (CSR):

// React
import { useEffect, useState } from 'react'

// Next.js
import Head from 'next/head'
import Link from 'next/link'

// Custom Components
import BackToHome from 'components/BackToHome'

// Page component
export default function ClientSideRendered() {

  const [state, setState] = useState([] as any)

  const getData = async () => {
    const res = await fetch('https://reqres.in/api/users?page=2')
    const jsonData = await res.json()
    setState(jsonData)
  }

  useEffect(() => {
    getData()
  }, [])

  return (
    <>
      <Head>
        <title>Client-Side Rendering (CSR) • Guy Dumais</title>
        <meta name="description" content="Example page using Client-Side Rendering (CSR) with Next.js 11 and React 17"/>
        <meta name="viewport" content="initial-scale=1.0, width=device-width" />
      </Head>
      <BackToHome/>
      <h1>Client-Side Rendering (CSR)</h1>
      <p>Data fetched on the client-side only.</p>
      <ul>
      {
        state.data?.map((e) => (
          <li key={e.id}>{e.email}</li>
        ))
      }
      </ul>
    </>
  )

}

Original article source at https://guydumais.digital

#next #nextjs #react

What is GEEK

Buddha Community

Next.js Cheat Sheet | Page Rendering with Next.js

JavaScript Daily

1632537859

NBB: Ad-hoc CLJS Scripting on Node.js

Nbb

Not babashka. Node.js babashka!?

Ad-hoc CLJS scripting on Node.js.

Status

Experimental. Please report issues here.

Goals and features

Nbb's main goal is to make it easy to get started with ad hoc CLJS scripting on Node.js.

Additional goals and features are:

Fast startup without relying on a custom version of Node.js.
Small artifact (current size is around 1.2MB).
First class macros.
Support building small TUI apps using Reagent.
Complement babashka with libraries from the Node.js ecosystem.

Requirements

Nbb requires Node.js v12 or newer.

How does this tool work?

CLJS code is evaluated through SCI, the same interpreter that powers babashka. Because SCI works with advanced compilation, the bundle size, especially when combined with other dependencies, is smaller than what you get with self-hosted CLJS. That makes startup faster. The trade-off is that execution is less performant and that only a subset of CLJS is available (e.g. no deftype, yet).

Usage

Install nbb from NPM:

$ npm install nbb -g

Omit -g for a local install.

Try out an expression:

$ nbb -e '(+ 1 2 3)'
6

And then install some other NPM libraries to use in the script. E.g.:

$ npm install csv-parse shelljs zx

Create a script which uses the NPM libraries:

(ns script
  (:require ["csv-parse/lib/sync$default" :as csv-parse]
            ["fs" :as fs]
            ["path" :as path]
            ["shelljs$default" :as sh]
            ["term-size$default" :as term-size]
            ["zx$default" :as zx]
            ["zx$fs" :as zxfs]
            [nbb.core :refer [*file*]]))

(prn (path/resolve "."))

(prn (term-size))

(println (count (str (fs/readFileSync *file*))))

(prn (sh/ls "."))

(prn (csv-parse "foo,bar"))

(prn (zxfs/existsSync *file*))

(zx/$ #js ["ls"])

Call the script:

$ nbb script.cljs
"/private/tmp/test-script"
#js {:columns 216, :rows 47}
510
#js ["node_modules" "package-lock.json" "package.json" "script.cljs"]
#js [#js ["foo" "bar"]]
true
$ ls
node_modules
package-lock.json
package.json
script.cljs

Macros

Nbb has first class support for macros: you can define them right inside your .cljs file, like you are used to from JVM Clojure. Consider the plet macro to make working with promises more palatable:

(defmacro plet
  [bindings & body]
  (let [binding-pairs (reverse (partition 2 bindings))
        body (cons 'do body)]
    (reduce (fn [body [sym expr]]
              (let [expr (list '.resolve 'js/Promise expr)]
                (list '.then expr (list 'clojure.core/fn (vector sym)
                                        body))))
            body
            binding-pairs)))

Using this macro we can look async code more like sync code. Consider this puppeteer example:

(-> (.launch puppeteer)
      (.then (fn [browser]
               (-> (.newPage browser)
                   (.then (fn [page]
                            (-> (.goto page "https://clojure.org")
                                (.then #(.screenshot page #js{:path "screenshot.png"}))
                                (.catch #(js/console.log %))
                                (.then #(.close browser)))))))))

Using plet this becomes:

(plet [browser (.launch puppeteer)
       page (.newPage browser)
       _ (.goto page "https://clojure.org")
       _ (-> (.screenshot page #js{:path "screenshot.png"})
             (.catch #(js/console.log %)))]
      (.close browser))

See the puppeteer example for the full code.

Since v0.0.36, nbb includes promesa which is a library to deal with promises. The above plet macro is similar to promesa.core/let.

Startup time

$ time nbb -e '(+ 1 2 3)'
6
nbb -e '(+ 1 2 3)'   0.17s  user 0.02s system 109% cpu 0.168 total

The baseline startup time for a script is about 170ms seconds on my laptop. When invoked via npx this adds another 300ms or so, so for faster startup, either use a globally installed nbb or use $(npm bin)/nbb script.cljs to bypass npx.

Dependencies

NPM dependencies

Nbb does not depend on any NPM dependencies. All NPM libraries loaded by a script are resolved relative to that script. When using the Reagent module, React is resolved in the same way as any other NPM library.

Classpath

To load .cljs files from local paths or dependencies, you can use the --classpath argument. The current dir is added to the classpath automatically. So if there is a file foo/bar.cljs relative to your current dir, then you can load it via (:require [foo.bar :as fb]). Note that nbb uses the same naming conventions for namespaces and directories as other Clojure tools: foo-bar in the namespace name becomes foo_bar in the directory name.

To load dependencies from the Clojure ecosystem, you can use the Clojure CLI or babashka to download them and produce a classpath:

$ classpath="$(clojure -A:nbb -Spath -Sdeps '{:aliases {:nbb {:replace-deps {com.github.seancorfield/honeysql {:git/tag "v2.0.0-rc5" :git/sha "01c3a55"}}}}}')"

and then feed it to the --classpath argument:

$ nbb --classpath "$classpath" -e "(require '[honey.sql :as sql]) (sql/format {:select :foo :from :bar :where [:= :baz 2]})"
["SELECT foo FROM bar WHERE baz = ?" 2]

Currently nbb only reads from directories, not jar files, so you are encouraged to use git libs. Support for .jar files will be added later.

Current file

The name of the file that is currently being executed is available via nbb.core/*file* or on the metadata of vars:

(ns foo
  (:require [nbb.core :refer [*file*]]))

(prn *file*) ;; "/private/tmp/foo.cljs"

(defn f [])
(prn (:file (meta #'f))) ;; "/private/tmp/foo.cljs"

Reagent

Nbb includes reagent.core which will be lazily loaded when required. You can use this together with ink to create a TUI application:

$ npm install ink

ink-demo.cljs:

(ns ink-demo
  (:require ["ink" :refer [render Text]]
            [reagent.core :as r]))

(defonce state (r/atom 0))

(doseq [n (range 1 11)]
  (js/setTimeout #(swap! state inc) (* n 500)))

(defn hello []
  [:> Text {:color "green"} "Hello, world! " @state])

(render (r/as-element [hello]))

Promesa

Working with callbacks and promises can become tedious. Since nbb v0.0.36 the promesa.core namespace is included with the let and do! macros. An example:

(ns prom
  (:require [promesa.core :as p]))

(defn sleep [ms]
  (js/Promise.
   (fn [resolve _]
     (js/setTimeout resolve ms))))

(defn do-stuff
  []
  (p/do!
   (println "Doing stuff which takes a while")
   (sleep 1000)
   1))

(p/let [a (do-stuff)
        b (inc a)
        c (do-stuff)
        d (+ b c)]
  (prn d))

$ nbb prom.cljs
Doing stuff which takes a while
Doing stuff which takes a while
3

Also see API docs.

Js-interop

Since nbb v0.0.75 applied-science/js-interop is available:

(ns example
  (:require [applied-science.js-interop :as j]))

(def o (j/lit {:a 1 :b 2 :c {:d 1}}))

(prn (j/select-keys o [:a :b])) ;; #js {:a 1, :b 2}
(prn (j/get-in o [:c :d])) ;; 1

Most of this library is supported in nbb, except the following:

destructuring using :syms
property access using .-x notation. In nbb, you must use keywords.

See the example of what is currently supported.

Examples

See the examples directory for small examples.

Also check out these projects built with nbb:

c64core: retrocompute aesthetics twitter bot
gallery.cljs: script to download walpapers from windowsonearth.org.
nbb-action-example: example of a Github action built with nbb.

API

See API documentation.

Migrating to shadow-cljs

See this gist on how to convert an nbb script or project to shadow-cljs.

Build

Prequisites:

babashka >= 0.4.0
Clojure CLI >= 1.10.3.933
Node.js 16.5.0 (lower version may work, but this is the one I used to build)

To build:

Clone and cd into this repo
bb release

Run bb tasks for more project-related tasks.

Download Details:
Author: borkdude
Download Link: Download The Source Code
Official Website: https://github.com/borkdude/nbb
License: EPL-1.0

#node #javascript

Eva Murphy

1625674200

Google analytics Setup with Next JS, React JS using Router Events - 14

In this video, we are going to implement Google Analytics to our Next JS application. Tracking page views of an application is very important.

Google analytics will allow us to track analytics information.

Frontend: https://github.com/amitavroy/video-reviews
API: https://github.com/amitavdevzone/video-review-api
App link: https://video-reviews.vercel.app

You can find me on:
Twitter: https://twitter.com/amitavroy7
Discord: https://discord.gg/Em4nuvQk

#next js #js #react js #react #next #google analytics

Beth Cooper

1659694200

Easy Activity Tracking for Models, Similar to Github's Public Activity

PublicActivity

public_activity provides easy activity tracking for your ActiveRecord, Mongoid 3 and MongoMapper models in Rails 3 and 4.

Simply put: it can record what happens in your application and gives you the ability to present those recorded activities to users - in a similar way to how GitHub does it.

!! WARNING: README for unreleased version below. !!

You probably don't want to read the docs for this unreleased version 2.0.

For the stable 1.5.X readme see: https://github.com/chaps-io/public_activity/blob/1-5-stable/README.md

About

Here is a simple example showing what this gem is about:

Example usage

Tutorials

Screencast

Ryan Bates made a great screencast describing how to integrate Public Activity.

Tutorial

A great step-by-step guide on implementing activity feeds using public_activity by Ilya Bodrov.

Online demo

You can see an actual application using this gem here: http://public-activity-example.herokuapp.com/feed

The source code of the demo is hosted here: https://github.com/pokonski/activity_blog

Setup

Gem installation

You can install public_activity as you would any other gem:

gem install public_activity

or in your Gemfile:

gem 'public_activity'

Database setup

By default public_activity uses Active Record. If you want to use Mongoid or MongoMapper as your backend, create an initializer file in your Rails application with the corresponding code inside:

For Mongoid:

# config/initializers/public_activity.rb
PublicActivity.configure do |config|
  config.orm = :mongoid
end

For MongoMapper:

# config/initializers/public_activity.rb
PublicActivity.configure do |config|
  config.orm = :mongo_mapper
end

(ActiveRecord only) Create migration for activities and migrate the database (in your Rails project):

rails g public_activity:migration
rake db:migrate

Model configuration

Include PublicActivity::Model and add tracked to the model you want to keep track of:

For ActiveRecord:

class Article < ActiveRecord::Base
  include PublicActivity::Model
  tracked
end

For Mongoid:

class Article
  include Mongoid::Document
  include PublicActivity::Model
  tracked
end

For MongoMapper:

class Article
  include MongoMapper::Document
  include PublicActivity::Model
  tracked
end

And now, by default create/update/destroy activities are recorded in activities table. This is all you need to start recording activities for basic CRUD actions.

Optional: If you don't need #tracked but still want the comfort of #create_activity, you can include only the lightweight Common module instead of Model.

Custom activities

You can trigger custom activities by setting all your required parameters and triggering create_activity on the tracked model, like this:

@article.create_activity key: 'article.commented_on', owner: current_user

See this entry http://rubydoc.info/gems/public_activity/PublicActivity/Common:create_activity for more details.

Displaying activities

To display them you simply query the PublicActivity::Activity model:

# notifications_controller.rb
def index
  @activities = PublicActivity::Activity.all
end

And in your views:

<%= render_activities(@activities) %>

Note: render_activities is an alias for render_activity and does the same.

Layouts

You can also pass options to both activity#render and #render_activity methods, which are passed deeper to the internally used render_partial method. A useful example would be to render activities wrapped in layout, which shares common elements of an activity, like a timestamp, owner's avatar etc:

<%= render_activities(@activities, layout: :activity) %>

The activity will be wrapped with the app/views/layouts/_activity.html.erb layout, in the above example.

Important: please note that layouts for activities are also partials. Hence the _ prefix.

Locals

Sometimes, it's desirable to pass additional local variables to partials. It can be done this way:

<%= render_activity(@activity, locals: {friends: current_user.friends}) %>

Note: Before 1.4.0, one could pass variables directly to the options hash for #render_activity and access it from activity parameters. This functionality is retained in 1.4.0 and later, but the :locals method is preferred, since it prevents bugs from shadowing variables from activity parameters in the database.

Activity views

public_activity looks for views in app/views/public_activity.

For example, if you have an activity with :key set to "activity.user.changed_avatar", the gem will look for a partial in app/views/public_activity/user/_changed_avatar.html.(|erb|haml|slim|something_else).

Hint: the "activity." prefix in :key is completely optional and kept for backwards compatibility, you can skip it in new projects.

If you would like to fallback to a partial, you can utilize the fallback parameter to specify the path of a partial to use when one is missing:

<%= render_activity(@activity, fallback: 'default') %>

When used in this manner, if a partial with the specified :key cannot be located it will use the partial defined in the fallback instead. In the example above this would resolve to public_activity/_default.html.(|erb|haml|slim|something_else).

If a view file does not exist then ActionView::MisingTemplate will be raised. If you wish to fallback to the old behaviour and use an i18n based translation in this situation you can specify a :fallback parameter of text to fallback to this mechanism like such:

<%= render_activity(@activity, fallback: :text) %>

i18n

Translations are used by the #text method, to which you can pass additional options in form of a hash. #render method uses translations when view templates have not been provided. You can render pure i18n strings by passing {display: :i18n} to #render_activity or #render.

Translations should be put in your locale .yml files. To render pure strings from I18n Example structure:

activity:
  article:
    create: 'Article has been created'
    update: 'Someone has edited the article'
    destroy: 'Some user removed an article!'

This structure is valid for activities with keys "activity.article.create" or "article.create". As mentioned before, "activity." part of the key is optional.

Testing

For RSpec you can first disable public_activity and add require helper methods in the rails_helper.rb with:

#rails_helper.rb
require 'public_activity/testing'

PublicActivity.enabled = false

In your specs you can then blockwise decide whether to turn public_activity on or off.

# file_spec.rb
PublicActivity.with_tracking do
  # your test code goes here
end

PublicActivity.without_tracking do
  # your test code goes here
end

Documentation

For more documentation go here

Common examples

Set the Activity's owner to current_user by default

You can set up a default value for :owner by doing this:

Include PublicActivity::StoreController in your ApplicationController like this:

class ApplicationController < ActionController::Base
  include PublicActivity::StoreController
end

Use Proc in :owner attribute for tracked class method in your desired model. For example:

class Article < ActiveRecord::Base
  tracked owner: Proc.new{ |controller, model| controller.current_user }
end

Note: current_user applies to Devise, if you are using a different authentication gem or your own code, change the current_user to a method you use.

Disable tracking for a class or globally

If you need to disable tracking temporarily, for example in tests or db/seeds.rb then you can use PublicActivity.enabled= attribute like below:

# Disable p_a globally
PublicActivity.enabled = false

# Perform some operations that would normally be tracked by p_a:
Article.create(title: 'New article')

# Switch it back on
PublicActivity.enabled = true

You can also disable public_activity for a specific class:

# Disable p_a for Article class
Article.public_activity_off

# p_a will not do anything here:
@article = Article.create(title: 'New article')

# But will be enabled for other classes:
# (creation of the comment will be recorded if you are tracking the Comment class)
@article.comments.create(body: 'some comment!')

# Enable it again for Article:
Article.public_activity_on

Create custom activities

Besides standard, automatic activities created on CRUD actions on your model (deactivatable), you can post your own activities that can be triggered without modifying the tracked model. There are a few ways to do this, as PublicActivity gives three tiers of options to be set.

Instant options

Because every activity needs a key (otherwise: NoKeyProvided is raised), the shortest and minimal way to post an activity is:

@user.create_activity :mood_changed
# the key of the action will be user.mood_changed
@user.create_activity action: :mood_changed # this is exactly the same as above

Besides assigning your key (which is obvious from the code), it will take global options from User class (given in #tracked method during class definition) and overwrite them with instance options (set on @user by #activity method). You can read more about options and how PublicActivity inherits them for you here.

Note the action parameter builds the key like this: "#{model_name}.#{action}". You can read further on options for #create_activity here.

To provide more options, you can do:

@user.create_activity action: 'poke', parameters: {reason: 'bored'}, recipient: @friend, owner: current_user

In this example, we have provided all the things we could for a standard Activity.

Use custom fields on Activity

Besides the few fields that every Activity has (key, owner, recipient, trackable, parameters), you can also set custom fields. This could be very beneficial, as parameters are a serialized hash, which cannot be queried easily from the database. That being said, use custom fields when you know that you will set them very often and search by them (don't forget database indexes :) ).

Set `owner` and `recipient` based on associations

class Comment < ActiveRecord::Base
  include PublicActivity::Model
  tracked owner: :commenter, recipient: :commentee

  belongs_to :commenter, :class_name => "User"
  belongs_to :commentee, :class_name => "User"
end

Resolve parameters from a Symbol or Proc

class Post < ActiveRecord::Base
  include PublicActivity::Model
  tracked only: [:update], parameters: :tracked_values
  
  def tracked_values
   {}.tap do |hash|
     hash[:tags] = tags if tags_changed?
   end
  end
end

Setup

Skip this step if you are using ActiveRecord in Rails 4 or Mongoid

The first step is similar in every ORM available (except mongoid):

PublicActivity::Activity.class_eval do
  attr_accessible :custom_field
end

place this code under config/initializers/public_activity.rb, you have to create it first.

To be able to assign to that field, we need to move it to the mass assignment sanitizer's whitelist.

Migration

If you're using ActiveRecord, you will also need to provide a migration to add the actual field to the Activity. Taken from our tests:

class AddCustomFieldToActivities < ActiveRecord::Migration
  def change
    change_table :activities do |t|
      t.string :custom_field
    end
  end
end

Assigning custom fields

Assigning is done by the same methods that you use for normal parameters: #tracked, #create_activity. You can just pass the name of your custom variable and assign its value. Even better, you can pass it to #tracked to tell us how to harvest your data for custom fields so we can do that for you.

class Article < ActiveRecord::Base
  include PublicActivity::Model
  tracked custom_field: proc {|controller, model| controller.some_helper }
end

Help

If you need help with using public_activity please visit our discussion group and ask a question there:

https://groups.google.com/forum/?fromgroups#!forum/public-activity

Please do not ask general questions in the Github Issues.

Author: public-activity
Source code: https://github.com/public-activity/public_activity
License: MIT license

#ruby #ruby-on-rails

Shawn Durgan

1626858956