Define enviroment variable whether if it's a server or client build

[Sebastian Fekete]

With webpacks DefinePlugin

There are serveral use cases this can be helpful to include some piece of code from the shared libararies only in a specific build.

It could be named "TARGET" = "client" || "server"

In the code then you can use for example:

if (process.env.TARGET == 'server') {
    apiBaseURL = '127.0.0.1:80'
    ...handleCookie passing...
}

etc.

This don't exposes server side code to the user.

[Nikolay]

I didn't understand what you said

[Vincent]

I think that @aight8 would like to have some kind of global variables to be able to know if the code is running on the client or on the server.
Something like:

if (_server_) {
    console.log("I'm executed on the server"); // Never logged on the browser
}

if (_client_) {
    console.log("I'm executed in the browser"); // Never logged on the server
}

With the help of Webpack DefinePlugin (https://github.com/webpack/docs/wiki/list-of-plugins#defineplugin) the finals builds will include only their related part.

[Nikolay]

This could be achieved in your webpack server-side configuration:

import { server_configuration } from 'universal-webpack'
import settings from './universal-webpack-settings'
import configuration from './webpack.config'

const config = server_configuration(configuration, settings)

config.plugins.push(new webpack.DefinePlugin
({
  __SERVER__ : JSON.stringify(true)
}))

export default config

[Sebastian Fekete]

Thanks for the code, thats exactly what I mean. No way to integrate it to something similar to the library itself? Benefits: Less userland code and same in every app.
It's a small thing but why should NOT this be in library? It make it for newcomes easier and more "complete" without hackig arround.
:)

PS: I love this project, it's so a transparent way to implement server side rendering. Hope it becomes more and more poular. Thanks for the work!

[Nikolay]

Well, I'm not sure it's needed as part of the library.
Maybe if enough people leave comments here then I may reconsider.

On Saturday, September 10, 2016, Sebastian Fekete [e-mail]
wrote:

Thanks for the code, thats exactly what I mean. No way to integrate it to
something similar to the library itself? Benefits: Less userland code and
same in every app.
It's a small thing but why should NOT this in library? Makes it for
newcomes easier.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#27 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAdH79DtcYW_ojOUBiTgN6zhiaerK3rMks5qof7CgaJpZM4J5YTr
.

[Sebastian Fekete]

👍