React Context Folder hiarchy / architecture?












1















I'm currently looking at implementing Context into one of our apps over Redux, but, I can't seem to find any information on what would be the best structure for large scale apps?



Redux has a defined way to create reducers, actions, etc. With Context, all I've found are the generic "create a provider, put state and methods all on the same file, and then use a consumer".



TL;DR Is there a way to build a hiarchy that is beneficial for long term, and large scale applications with React Context?



Edit: I guess this is incorrect to think of them having a similar structured relationship. Unfortunately, I'm not able to use Redux because of AEM's limitations. Context does work however, so I wanted to hopefully be able to build some structure with that.










share|improve this question

























  • "over Redux" - you mean replacing Redux with Context? If that's the case, I wouldn't recommend this. "Apply it sparingly because it makes component reuse more difficult." - from Context docs. I'd look into component composition instead.

    – chazsolo
    Nov 21 '18 at 14:02











  • I need to update reason behind it on my post. I can't use Redux with AEM, so have to find an alternative that may work... Such as Context, which I don't want to be messy.

    – Bryce Snyder
    Nov 21 '18 at 14:58
















1















I'm currently looking at implementing Context into one of our apps over Redux, but, I can't seem to find any information on what would be the best structure for large scale apps?



Redux has a defined way to create reducers, actions, etc. With Context, all I've found are the generic "create a provider, put state and methods all on the same file, and then use a consumer".



TL;DR Is there a way to build a hiarchy that is beneficial for long term, and large scale applications with React Context?



Edit: I guess this is incorrect to think of them having a similar structured relationship. Unfortunately, I'm not able to use Redux because of AEM's limitations. Context does work however, so I wanted to hopefully be able to build some structure with that.










share|improve this question

























  • "over Redux" - you mean replacing Redux with Context? If that's the case, I wouldn't recommend this. "Apply it sparingly because it makes component reuse more difficult." - from Context docs. I'd look into component composition instead.

    – chazsolo
    Nov 21 '18 at 14:02











  • I need to update reason behind it on my post. I can't use Redux with AEM, so have to find an alternative that may work... Such as Context, which I don't want to be messy.

    – Bryce Snyder
    Nov 21 '18 at 14:58














1












1








1








I'm currently looking at implementing Context into one of our apps over Redux, but, I can't seem to find any information on what would be the best structure for large scale apps?



Redux has a defined way to create reducers, actions, etc. With Context, all I've found are the generic "create a provider, put state and methods all on the same file, and then use a consumer".



TL;DR Is there a way to build a hiarchy that is beneficial for long term, and large scale applications with React Context?



Edit: I guess this is incorrect to think of them having a similar structured relationship. Unfortunately, I'm not able to use Redux because of AEM's limitations. Context does work however, so I wanted to hopefully be able to build some structure with that.










share|improve this question
















I'm currently looking at implementing Context into one of our apps over Redux, but, I can't seem to find any information on what would be the best structure for large scale apps?



Redux has a defined way to create reducers, actions, etc. With Context, all I've found are the generic "create a provider, put state and methods all on the same file, and then use a consumer".



TL;DR Is there a way to build a hiarchy that is beneficial for long term, and large scale applications with React Context?



Edit: I guess this is incorrect to think of them having a similar structured relationship. Unfortunately, I'm not able to use Redux because of AEM's limitations. Context does work however, so I wanted to hopefully be able to build some structure with that.







javascript reactjs






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 21 '18 at 14:58







Bryce Snyder

















asked Nov 21 '18 at 13:52









Bryce SnyderBryce Snyder

243318




243318













  • "over Redux" - you mean replacing Redux with Context? If that's the case, I wouldn't recommend this. "Apply it sparingly because it makes component reuse more difficult." - from Context docs. I'd look into component composition instead.

    – chazsolo
    Nov 21 '18 at 14:02











  • I need to update reason behind it on my post. I can't use Redux with AEM, so have to find an alternative that may work... Such as Context, which I don't want to be messy.

    – Bryce Snyder
    Nov 21 '18 at 14:58



















  • "over Redux" - you mean replacing Redux with Context? If that's the case, I wouldn't recommend this. "Apply it sparingly because it makes component reuse more difficult." - from Context docs. I'd look into component composition instead.

    – chazsolo
    Nov 21 '18 at 14:02











  • I need to update reason behind it on my post. I can't use Redux with AEM, so have to find an alternative that may work... Such as Context, which I don't want to be messy.

    – Bryce Snyder
    Nov 21 '18 at 14:58

















"over Redux" - you mean replacing Redux with Context? If that's the case, I wouldn't recommend this. "Apply it sparingly because it makes component reuse more difficult." - from Context docs. I'd look into component composition instead.

– chazsolo
Nov 21 '18 at 14:02





"over Redux" - you mean replacing Redux with Context? If that's the case, I wouldn't recommend this. "Apply it sparingly because it makes component reuse more difficult." - from Context docs. I'd look into component composition instead.

– chazsolo
Nov 21 '18 at 14:02













I need to update reason behind it on my post. I can't use Redux with AEM, so have to find an alternative that may work... Such as Context, which I don't want to be messy.

– Bryce Snyder
Nov 21 '18 at 14:58





I need to update reason behind it on my post. I can't use Redux with AEM, so have to find an alternative that may work... Such as Context, which I don't want to be messy.

– Bryce Snyder
Nov 21 '18 at 14:58












1 Answer
1






active

oldest

votes


















1














First of all, I don't think there is necessarily a right or wrong answer to this question, but I will just give you my two cents.



I am currently refactoring a web application which serves several millions of sessions per month and am testing a redux and context version on internal stage servers.



Important notices:




  • I am using a mono-store approach

  • It's not an app which constantly has global store updates


To the folder structure. I like to keep my store in the root of the project. For a react app based on react-create-react-app that would be the /src and it basically consists of the following files:




  • index.js // everything gets "bundled" here

  • initialState.js // provides the store with intial state e.g. from server, cache etc.

  • methods/*.js // contains split methods based on the part of the app that they are used in (if it can be split into separate parts)


Ergo my index.js is as simple as:



import React from 'react';
import storeMethods from './methods';
import initialState from './initialState';

// to start of experimenting with context
// i would keep all read and write key value
// pairs right here and split as the codebase
// grows and you realize you need more space
export const store = {
...initialState,
...storeMethods
}

export const StoreContext = React.createContext(store)


storeMethods is a bundled export from all methods in the methods/ folder. Basically it's just another object of containing keys which values are functions like so:



export const methods = {
showNavBar: function() {
this.setState({ navBarOpen: true })
}
}


initialState is as much as the representation of key value pairs that are required to render the base content of the app and or never change. Basically some global settings. Initialstate coming from the server, is being added to the store in the constructor of my App, right before I bind the lexical scope.



The store get's thrown into the state of the relevant outermost React Component and is used as the app state, where I bind the store's scope to the React Components lexical scope.



Then I have a higher order component withContextConsumer which is used to wrap any React component which needs access to the state. The HOC distributes the subscribed keys down as props to the wrapped component and can be consumed as read only or write.



No matter how you end up using Context, don't forget, that any Consumer will have it's render method automatically called if the Context Store is being updated. To avoid that on a simple oldProps !== newProps level, you can use PureComponents. For more complex diffs you can use the lifecyclemethod shouldComponentUpdate



edit



Basic App Structure



App.js:



import React, { PureComponent } from 'react'
import { StoreContext, store } from './store'
import { bindScopeToFunction } from './helpers'

class App extends PureComponent {
constructor(props) {
super(props)
const { initialState = {} } = props
const boundStore = bindScopeToFunction(store, this)
this.state = {...boundStore, ...initialState}
}
render () {
return(
<StoreContext.Provider value={this.state}>
// in here you render all your app
// routing, childcomponents etc
// in any component where you need access
// to the global store
// wrap it in <StoreContext.Consumer> it has
// the whole store as render prop
</StoreContext.Provider>
)
}
}


Working basic example can be found here https://codesandbox.io/s/pm85w4y6xm






share|improve this answer


























  • This makes me feel a lot better.. Could you possibly share some code examples for what you're doing in your storeMethods and initialState?

    – Bryce Snyder
    Nov 21 '18 at 15:19








  • 1





    Hope this helps in a way. We are in an interesting state, where no big player wrote any structured blogg article about how to and how not to use context. So I am currently experimenting with this approach. But also developing a redux version along the way to swap it out if it fails hard.

    – noa-dev
    Nov 21 '18 at 15:28











  • Tried to get your answer to work, don't understand the structure overall for providers etc with this.. :(

    – Bryce Snyder
    Nov 21 '18 at 16:48






  • 1





    Updated my answer

    – noa-dev
    Nov 22 '18 at 6:57











  • No example of binding methods on there?

    – Bryce Snyder
    Nov 22 '18 at 15:32











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53413610%2freact-context-folder-hiarchy-architecture%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









1














First of all, I don't think there is necessarily a right or wrong answer to this question, but I will just give you my two cents.



I am currently refactoring a web application which serves several millions of sessions per month and am testing a redux and context version on internal stage servers.



Important notices:




  • I am using a mono-store approach

  • It's not an app which constantly has global store updates


To the folder structure. I like to keep my store in the root of the project. For a react app based on react-create-react-app that would be the /src and it basically consists of the following files:




  • index.js // everything gets "bundled" here

  • initialState.js // provides the store with intial state e.g. from server, cache etc.

  • methods/*.js // contains split methods based on the part of the app that they are used in (if it can be split into separate parts)


Ergo my index.js is as simple as:



import React from 'react';
import storeMethods from './methods';
import initialState from './initialState';

// to start of experimenting with context
// i would keep all read and write key value
// pairs right here and split as the codebase
// grows and you realize you need more space
export const store = {
...initialState,
...storeMethods
}

export const StoreContext = React.createContext(store)


storeMethods is a bundled export from all methods in the methods/ folder. Basically it's just another object of containing keys which values are functions like so:



export const methods = {
showNavBar: function() {
this.setState({ navBarOpen: true })
}
}


initialState is as much as the representation of key value pairs that are required to render the base content of the app and or never change. Basically some global settings. Initialstate coming from the server, is being added to the store in the constructor of my App, right before I bind the lexical scope.



The store get's thrown into the state of the relevant outermost React Component and is used as the app state, where I bind the store's scope to the React Components lexical scope.



Then I have a higher order component withContextConsumer which is used to wrap any React component which needs access to the state. The HOC distributes the subscribed keys down as props to the wrapped component and can be consumed as read only or write.



No matter how you end up using Context, don't forget, that any Consumer will have it's render method automatically called if the Context Store is being updated. To avoid that on a simple oldProps !== newProps level, you can use PureComponents. For more complex diffs you can use the lifecyclemethod shouldComponentUpdate



edit



Basic App Structure



App.js:



import React, { PureComponent } from 'react'
import { StoreContext, store } from './store'
import { bindScopeToFunction } from './helpers'

class App extends PureComponent {
constructor(props) {
super(props)
const { initialState = {} } = props
const boundStore = bindScopeToFunction(store, this)
this.state = {...boundStore, ...initialState}
}
render () {
return(
<StoreContext.Provider value={this.state}>
// in here you render all your app
// routing, childcomponents etc
// in any component where you need access
// to the global store
// wrap it in <StoreContext.Consumer> it has
// the whole store as render prop
</StoreContext.Provider>
)
}
}


Working basic example can be found here https://codesandbox.io/s/pm85w4y6xm






share|improve this answer


























  • This makes me feel a lot better.. Could you possibly share some code examples for what you're doing in your storeMethods and initialState?

    – Bryce Snyder
    Nov 21 '18 at 15:19








  • 1





    Hope this helps in a way. We are in an interesting state, where no big player wrote any structured blogg article about how to and how not to use context. So I am currently experimenting with this approach. But also developing a redux version along the way to swap it out if it fails hard.

    – noa-dev
    Nov 21 '18 at 15:28











  • Tried to get your answer to work, don't understand the structure overall for providers etc with this.. :(

    – Bryce Snyder
    Nov 21 '18 at 16:48






  • 1





    Updated my answer

    – noa-dev
    Nov 22 '18 at 6:57











  • No example of binding methods on there?

    – Bryce Snyder
    Nov 22 '18 at 15:32
















1














First of all, I don't think there is necessarily a right or wrong answer to this question, but I will just give you my two cents.



I am currently refactoring a web application which serves several millions of sessions per month and am testing a redux and context version on internal stage servers.



Important notices:




  • I am using a mono-store approach

  • It's not an app which constantly has global store updates


To the folder structure. I like to keep my store in the root of the project. For a react app based on react-create-react-app that would be the /src and it basically consists of the following files:




  • index.js // everything gets "bundled" here

  • initialState.js // provides the store with intial state e.g. from server, cache etc.

  • methods/*.js // contains split methods based on the part of the app that they are used in (if it can be split into separate parts)


Ergo my index.js is as simple as:



import React from 'react';
import storeMethods from './methods';
import initialState from './initialState';

// to start of experimenting with context
// i would keep all read and write key value
// pairs right here and split as the codebase
// grows and you realize you need more space
export const store = {
...initialState,
...storeMethods
}

export const StoreContext = React.createContext(store)


storeMethods is a bundled export from all methods in the methods/ folder. Basically it's just another object of containing keys which values are functions like so:



export const methods = {
showNavBar: function() {
this.setState({ navBarOpen: true })
}
}


initialState is as much as the representation of key value pairs that are required to render the base content of the app and or never change. Basically some global settings. Initialstate coming from the server, is being added to the store in the constructor of my App, right before I bind the lexical scope.



The store get's thrown into the state of the relevant outermost React Component and is used as the app state, where I bind the store's scope to the React Components lexical scope.



Then I have a higher order component withContextConsumer which is used to wrap any React component which needs access to the state. The HOC distributes the subscribed keys down as props to the wrapped component and can be consumed as read only or write.



No matter how you end up using Context, don't forget, that any Consumer will have it's render method automatically called if the Context Store is being updated. To avoid that on a simple oldProps !== newProps level, you can use PureComponents. For more complex diffs you can use the lifecyclemethod shouldComponentUpdate



edit



Basic App Structure



App.js:



import React, { PureComponent } from 'react'
import { StoreContext, store } from './store'
import { bindScopeToFunction } from './helpers'

class App extends PureComponent {
constructor(props) {
super(props)
const { initialState = {} } = props
const boundStore = bindScopeToFunction(store, this)
this.state = {...boundStore, ...initialState}
}
render () {
return(
<StoreContext.Provider value={this.state}>
// in here you render all your app
// routing, childcomponents etc
// in any component where you need access
// to the global store
// wrap it in <StoreContext.Consumer> it has
// the whole store as render prop
</StoreContext.Provider>
)
}
}


Working basic example can be found here https://codesandbox.io/s/pm85w4y6xm






share|improve this answer


























  • This makes me feel a lot better.. Could you possibly share some code examples for what you're doing in your storeMethods and initialState?

    – Bryce Snyder
    Nov 21 '18 at 15:19








  • 1





    Hope this helps in a way. We are in an interesting state, where no big player wrote any structured blogg article about how to and how not to use context. So I am currently experimenting with this approach. But also developing a redux version along the way to swap it out if it fails hard.

    – noa-dev
    Nov 21 '18 at 15:28











  • Tried to get your answer to work, don't understand the structure overall for providers etc with this.. :(

    – Bryce Snyder
    Nov 21 '18 at 16:48






  • 1





    Updated my answer

    – noa-dev
    Nov 22 '18 at 6:57











  • No example of binding methods on there?

    – Bryce Snyder
    Nov 22 '18 at 15:32














1












1








1







First of all, I don't think there is necessarily a right or wrong answer to this question, but I will just give you my two cents.



I am currently refactoring a web application which serves several millions of sessions per month and am testing a redux and context version on internal stage servers.



Important notices:




  • I am using a mono-store approach

  • It's not an app which constantly has global store updates


To the folder structure. I like to keep my store in the root of the project. For a react app based on react-create-react-app that would be the /src and it basically consists of the following files:




  • index.js // everything gets "bundled" here

  • initialState.js // provides the store with intial state e.g. from server, cache etc.

  • methods/*.js // contains split methods based on the part of the app that they are used in (if it can be split into separate parts)


Ergo my index.js is as simple as:



import React from 'react';
import storeMethods from './methods';
import initialState from './initialState';

// to start of experimenting with context
// i would keep all read and write key value
// pairs right here and split as the codebase
// grows and you realize you need more space
export const store = {
...initialState,
...storeMethods
}

export const StoreContext = React.createContext(store)


storeMethods is a bundled export from all methods in the methods/ folder. Basically it's just another object of containing keys which values are functions like so:



export const methods = {
showNavBar: function() {
this.setState({ navBarOpen: true })
}
}


initialState is as much as the representation of key value pairs that are required to render the base content of the app and or never change. Basically some global settings. Initialstate coming from the server, is being added to the store in the constructor of my App, right before I bind the lexical scope.



The store get's thrown into the state of the relevant outermost React Component and is used as the app state, where I bind the store's scope to the React Components lexical scope.



Then I have a higher order component withContextConsumer which is used to wrap any React component which needs access to the state. The HOC distributes the subscribed keys down as props to the wrapped component and can be consumed as read only or write.



No matter how you end up using Context, don't forget, that any Consumer will have it's render method automatically called if the Context Store is being updated. To avoid that on a simple oldProps !== newProps level, you can use PureComponents. For more complex diffs you can use the lifecyclemethod shouldComponentUpdate



edit



Basic App Structure



App.js:



import React, { PureComponent } from 'react'
import { StoreContext, store } from './store'
import { bindScopeToFunction } from './helpers'

class App extends PureComponent {
constructor(props) {
super(props)
const { initialState = {} } = props
const boundStore = bindScopeToFunction(store, this)
this.state = {...boundStore, ...initialState}
}
render () {
return(
<StoreContext.Provider value={this.state}>
// in here you render all your app
// routing, childcomponents etc
// in any component where you need access
// to the global store
// wrap it in <StoreContext.Consumer> it has
// the whole store as render prop
</StoreContext.Provider>
)
}
}


Working basic example can be found here https://codesandbox.io/s/pm85w4y6xm






share|improve this answer















First of all, I don't think there is necessarily a right or wrong answer to this question, but I will just give you my two cents.



I am currently refactoring a web application which serves several millions of sessions per month and am testing a redux and context version on internal stage servers.



Important notices:




  • I am using a mono-store approach

  • It's not an app which constantly has global store updates


To the folder structure. I like to keep my store in the root of the project. For a react app based on react-create-react-app that would be the /src and it basically consists of the following files:




  • index.js // everything gets "bundled" here

  • initialState.js // provides the store with intial state e.g. from server, cache etc.

  • methods/*.js // contains split methods based on the part of the app that they are used in (if it can be split into separate parts)


Ergo my index.js is as simple as:



import React from 'react';
import storeMethods from './methods';
import initialState from './initialState';

// to start of experimenting with context
// i would keep all read and write key value
// pairs right here and split as the codebase
// grows and you realize you need more space
export const store = {
...initialState,
...storeMethods
}

export const StoreContext = React.createContext(store)


storeMethods is a bundled export from all methods in the methods/ folder. Basically it's just another object of containing keys which values are functions like so:



export const methods = {
showNavBar: function() {
this.setState({ navBarOpen: true })
}
}


initialState is as much as the representation of key value pairs that are required to render the base content of the app and or never change. Basically some global settings. Initialstate coming from the server, is being added to the store in the constructor of my App, right before I bind the lexical scope.



The store get's thrown into the state of the relevant outermost React Component and is used as the app state, where I bind the store's scope to the React Components lexical scope.



Then I have a higher order component withContextConsumer which is used to wrap any React component which needs access to the state. The HOC distributes the subscribed keys down as props to the wrapped component and can be consumed as read only or write.



No matter how you end up using Context, don't forget, that any Consumer will have it's render method automatically called if the Context Store is being updated. To avoid that on a simple oldProps !== newProps level, you can use PureComponents. For more complex diffs you can use the lifecyclemethod shouldComponentUpdate



edit



Basic App Structure



App.js:



import React, { PureComponent } from 'react'
import { StoreContext, store } from './store'
import { bindScopeToFunction } from './helpers'

class App extends PureComponent {
constructor(props) {
super(props)
const { initialState = {} } = props
const boundStore = bindScopeToFunction(store, this)
this.state = {...boundStore, ...initialState}
}
render () {
return(
<StoreContext.Provider value={this.state}>
// in here you render all your app
// routing, childcomponents etc
// in any component where you need access
// to the global store
// wrap it in <StoreContext.Consumer> it has
// the whole store as render prop
</StoreContext.Provider>
)
}
}


Working basic example can be found here https://codesandbox.io/s/pm85w4y6xm







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 22 '18 at 7:52

























answered Nov 21 '18 at 15:17









noa-devnoa-dev

1,88242149




1,88242149













  • This makes me feel a lot better.. Could you possibly share some code examples for what you're doing in your storeMethods and initialState?

    – Bryce Snyder
    Nov 21 '18 at 15:19








  • 1





    Hope this helps in a way. We are in an interesting state, where no big player wrote any structured blogg article about how to and how not to use context. So I am currently experimenting with this approach. But also developing a redux version along the way to swap it out if it fails hard.

    – noa-dev
    Nov 21 '18 at 15:28











  • Tried to get your answer to work, don't understand the structure overall for providers etc with this.. :(

    – Bryce Snyder
    Nov 21 '18 at 16:48






  • 1





    Updated my answer

    – noa-dev
    Nov 22 '18 at 6:57











  • No example of binding methods on there?

    – Bryce Snyder
    Nov 22 '18 at 15:32



















  • This makes me feel a lot better.. Could you possibly share some code examples for what you're doing in your storeMethods and initialState?

    – Bryce Snyder
    Nov 21 '18 at 15:19








  • 1





    Hope this helps in a way. We are in an interesting state, where no big player wrote any structured blogg article about how to and how not to use context. So I am currently experimenting with this approach. But also developing a redux version along the way to swap it out if it fails hard.

    – noa-dev
    Nov 21 '18 at 15:28











  • Tried to get your answer to work, don't understand the structure overall for providers etc with this.. :(

    – Bryce Snyder
    Nov 21 '18 at 16:48






  • 1





    Updated my answer

    – noa-dev
    Nov 22 '18 at 6:57











  • No example of binding methods on there?

    – Bryce Snyder
    Nov 22 '18 at 15:32

















This makes me feel a lot better.. Could you possibly share some code examples for what you're doing in your storeMethods and initialState?

– Bryce Snyder
Nov 21 '18 at 15:19







This makes me feel a lot better.. Could you possibly share some code examples for what you're doing in your storeMethods and initialState?

– Bryce Snyder
Nov 21 '18 at 15:19






1




1





Hope this helps in a way. We are in an interesting state, where no big player wrote any structured blogg article about how to and how not to use context. So I am currently experimenting with this approach. But also developing a redux version along the way to swap it out if it fails hard.

– noa-dev
Nov 21 '18 at 15:28





Hope this helps in a way. We are in an interesting state, where no big player wrote any structured blogg article about how to and how not to use context. So I am currently experimenting with this approach. But also developing a redux version along the way to swap it out if it fails hard.

– noa-dev
Nov 21 '18 at 15:28













Tried to get your answer to work, don't understand the structure overall for providers etc with this.. :(

– Bryce Snyder
Nov 21 '18 at 16:48





Tried to get your answer to work, don't understand the structure overall for providers etc with this.. :(

– Bryce Snyder
Nov 21 '18 at 16:48




1




1





Updated my answer

– noa-dev
Nov 22 '18 at 6:57





Updated my answer

– noa-dev
Nov 22 '18 at 6:57













No example of binding methods on there?

– Bryce Snyder
Nov 22 '18 at 15:32





No example of binding methods on there?

– Bryce Snyder
Nov 22 '18 at 15:32


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53413610%2freact-context-folder-hiarchy-architecture%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

"Incorrect syntax near the keyword 'ON'. (on update cascade, on delete cascade,)

Alcedinidae

Origin of the phrase “under your belt”?