Docs · Nuxt Community

Activities

padinko posted a new question

docs •

Add $nuxt.refresh to documentation

Is your feature request related to a problem? Please describe.

Changelog for v2.9.0 says you added $nuxt.refresh but there is no documentation about it.
I am using this function to reload data from async data. Is it correct usage?
Everytime I want to use it and can't remember the function name (I always trying $refresh $reload etc.) i cant find it on docs.

Describe the solution you'd like

Add $nuxt.refresh to documentation with ifnrom what it is for and how to use it.

drewbaker posted a new feature request

docs •

Some documentation on how to use runtime config vars in nuxt.config.js in multiple places or a plugin?

What problem does this feature solve?

Currently it seems you need to use .env vars and set their defaults in multiple places. For example:

// nuxt.config.js
export default {
  publicRuntimeConfig: {
    host: process.env.HOST || "0.0.0.0"
    endpoint: process.env.DEFAULT_ENDPOINT
  },
  server: {
      host: process.env.HOST || "0.0.0.0"
  },
    apollo: {
        authenticationType: "Basic",
        clientConfigs: {
            default: "~/plugins/apollo-config-default.js"
        }
    },
}

// ~/plugins/apollo-config-default.js
export default function() {
    return {
        httpEndpoint: process.env.DEFAULT_ENDPOINT,
        getAuth: () => process.env.BASIC_API_TOKEN || "",
        httpLinkOptions: {
            credentials: "include"
        }
    }
}

Having two defaults is going against the whole point of a .env file.

What does the proposed changes look like?

Ideally you have some documentation showing how to access publicRuntimeConfig.varName in your nuxt.config or other files that gets imported into nuxt.config like the above Apollo example.

hanshou101 posted a new question

docs •

【zh/api/configuration-dev.md】 Some chapters in the document, code and document description, can not correspond one to one

In the last section of the document, the code given is :

"start": "NODE_ENV=production node server.js"

And the documentation given is :

注意: 要运行上面的示例，你需要运行 npm install --save-dev cross-env 安装 cross-env。

There is ambiguity here, because in the sample code, the library [cross-env] does not appear .

mornir posted a new feature request

docs •

Document enablePreview

To-do list

Explain that enablePreview accepts data for override (e.g. draft data from a CMS)
Explain asyncData({$preview}) and this.$preview
Inform that enablePreview uses $nuxt.refresh under the hood. So basically what happens is a client side refresh.
Give a good example of usage (e.g. fetching draft data from CMS).
Inform that enablePreview should be tested locally with yarn serve and not yarn dev (I tested it, in dev mode, enablePreview doesn't work as expected in the asyncData hook, which is normal)
Inform that enablePreview is only available in the context object of plugins
Inform that previews are handled client-side and thus the plugin should be run on the client preview.client.js
Give an example for previewing draft content (not publicly available) (see this thread)
Warn about the validate hook. Preview mode should also be checked in the validate hook.

Existing sources:
https://github.com/nuxt/nuxt.js/blob/0337932115d4312130d266962d469620378af61c/packages/vue-app/template/index.js#L214
https://nuxtjs.org/blog/going-full-static/

I can submit a contribution to the docs, but I don't know exactly where I should publish it on nuxt.org. Under plugins?
I was thinking that I could also write a real-word example with Sanity CMS and publish it under https://nuxtjs.org/examples

r9mp posted a new question

docs •

ko: FAQ Deploy using PM2 redirects to NginX

(I was not able to use cmty => not possible to specify a version after selecting Bug report- Firefox 77.0.1 64bits ; Ubuntu 18.4.4 LTS)

Reproduction link
https://nuxtjs.org/faq/nginx-proxy

Steps to reproduce
Go to https://nuxtjs.org
Click on FAQ at the top
On the left menu, in DEPLOYMENT section, click on "Deploy using PM2 cluster mode"

What is expected ?
Deploy using PM2 should be displayed

What is actually happening?
Using nginx as a proxy is displayed

Additional comments?
I did this dev ; made an URL mistake in menu.json file! SORRY
I am creating a new MR with the fix

stuft2 posted a new feature request

docs •

Update Installation Docs to Reflect New Installation Process

What problem does this feature solve?

The Installation documentation page leaves out some crucial elements that developers are bound to have questions about. For example: when choosing TypeScript as your programming language, a follow up questions asks you to choose the runtime for TypeScript. The only way a developer could know more about this option is to find the feature request on GitHub and follow the conversation.

I propose that the Installation documentation page be updated to reflect exactly what the installation process is and continues to provide links or short descriptions of each option. If implemented, this will help developers (especially rookies) understand the components they want or can install, provide them a direction to learn about topics they are unfamiliar with, and complete the documentation so nothing is missing.

What does the proposed changes look like?

The Installation documentation page will better reflect all the steps and options available in the create-nuxt-app installation process.

FloEdelmann posted a new feature request

docs •

Add "style guide" to docs

What problem does this feature solve?

It would be helpful to have a style guide, similar to Vue's (https://vuejs.org/v2/style-guide/), so that arbitrary choice in Nuxt.js apps is further reduced. Those guidelines could be enforced with a linter, like ESLint or its Vue Plugin.

In particular, a "Component options order" rule came to my mind (similar to https://vuejs.org/v2/style-guide/#Component-instance-options-order-recommended). I've already opened a PR (#1107) to eslint-plugin-vue. Please comment there on the suggested order.

clarkdo posted a new feature request

docs •

Add description for `runInNewContext: false` in dev mode

What problem does this feature solve?

Issue: https://github.com/nuxt/nuxt.js/issues/7266

brfrth posted a new question

docs •

Documentation for fetch does not describe use with Vuex

The old fetch was commonly used for Vuex initializing. This is still apparent when looking at the description of fetch on the Vuex guide page.

The fetch method is used to fill the store before rendering the page, it's like the asyncData method except it doesn't set the component data.

However, when clicking the link to the fetch API page inside the guide, you get shown the new fetch which modifies component data directly. There is no sign of any Vuex examples there and the usage is quite unclear. In fact the description on the Vuex guide page matches that on the fetch API page under the old fetch. This might encourage implementing logic based on old fetch. Someone who is starting out might get confused at this point as there is no clear path for setting up Vuex and initializing it with asynchronous data on the client side.

My suggestion would be either expanding the fetch documentation on the Vuex store guide page or adding an example for Vuex usage on the fetch API page.

gbezyuk posted a new feature request

docs •

Adding Module Resolution / Import Paths and Aliases Instructions

What problem does this feature solve?

Let's say I use a nuxt-based app as a testbed for some @my-name-space/** packages. I've created a nuxt-based app and added @my-name-space as a root folder, under which I store all the stuff I want to use in my testbed.

I want imports like import MyStuff from @my-name-space/some/Stuff work. So, I need to update jsconfig.json, tsconfig.json, and most importantly to extend my nuxt.config.js with the following code:

{
 /*
  ** Build configuration
  */
  build: {
    /*
    ** You can extend webpack config here
    */
    extend (config, ctx) {
      // allow @my-name-space imports
      config.resolve.alias['@my-name-space'] = config.resolve.alias['~'] + '/@my-name-space'
    }
  }

With some trial & error I managed to achieve the desired result. Wouldn't it be nice to have a documentation entry so the next guy with the same goal in mind could save some time?

What does the proposed changes look like?

A new documentation entry, titled something like "adding import path aliases".

mrleblanc101 posted a new question

docs •

Bottom Navbar safe-area-inset

Hi,
I just noticed the Nuxt Doc was updated (haven't used in a little bit)to use a bottom Navigation bar on mobile and there's an issue on iPhone X. The bar does not respect the safe-area-inset for the home indicator.

MangoSeven posted a new question

docs •

Why autoprefixer doesn't work？

Official website add autoprefixer . but autoprefixer doesn't work.
build: {
postcss: {
// 添加插件名称作为键，参数作为值
// 使用npm或yarn安装它们
plugins: {
'postcss-pxtorem': {
remUnit: 75
},
},
preset: {
// 更改postcss-preset-env 设置
autoprefixer: { grid: true }
}
}
}

davestewart posted a new feature request

docs •

Make the API sections and examples more consistent and verbose where needed

What problem does this feature solve?

As a new Nuxt user, I found the configuration sections quite inconsistent:

some show the full config from export default { thing: { ... } } others just the block { ... }
some say "nuxt.config.js" others don't
some give full explanations, others don't

In the html.minify section, because there was no "full" example, I buggered about with various examples: 'html.minify': { ... }, html: { minify: {} }, and because of other docs online even htmlMinify but none seemed to work.

There there was code online and in the source about Nuxt's generate script and associated config (other than build).

Then I found out html minifier was a module, and needed to be included. When I added them, the feature half-worked:

As a new (but advanced) user, it's frustrating to thrash around on the margins but see intermittent progress.

Having sections like these fully documented and tested is critical.

What does the proposed changes look like?

Deciding what would be a good format:

file name
config format
examples
dependencies (if relevant)

and sticking to it.

Perhaps also having some way to review the docs / releases to see what should be updated.

WernerRaath posted a new bug report

docs •

Nginx example requires commercial subscription

Reproduction link

https://nuxtjs.org/faq/nginx-proxy/#using-nginx-with-generated-pages-and-a-caching-proxy-as-fallback

Steps to reproduce

Apply this Nginx conf with an non-commercial Nginx service.

What is expected ?

Nginx should start up

What is actually happening?

Get this error:
nginx: [emerg] unknown directive "proxycachepurge" in /etc/nginx/conf.d/default.conf

Additional comments?

I would just recommend that you update the document to state that and Nginx commercial license is required as stated here: http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_purge

WernerRaath posted a new question

docs •

Nginx on static content only

This relates to the nginx-proxy.md example.

I am weighing up the difference between

serving the app via npm run start with Nginx pointing to it as the document describes, or
just serving up the dist folder behind Nginx.

Since I'm using Docker containers, I would like to try and just serve this web app up with one container instead of 2 for scaling purposes.

My application is a PWA that simply fetches, caches and displays data with some minor additional functionality.

Are there cons to serving it up behind Nginx only?

I have tested it behind Nginx only and everything works fine, but I don't know if there's any additional logic that serving it up via node provides.

The new Nginx (without all my API reverse proxies) looks like:

server {
    listen 80;
    server_name my.domain.name;

    gzip            on;
    gzip_types      text/plain application/xml text/css application/javascript;
    gzip_min_length 1000;
    location / {
        root               /usr/local/static/;
        index              index.html;
    }
}