React Context Folder hiarchy / architecture?
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
add a comment |
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
"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
add a comment |
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
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
javascript reactjs
edited Nov 21 '18 at 14:58
asked Nov 21 '18 at 13:52
Bryce Snyder
238317
238317
"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
add a comment |
"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
add a comment |
1 Answer
1
active
oldest
votes
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
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
|
show 1 more comment
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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
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
|
show 1 more comment
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
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
|
show 1 more comment
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
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
edited Nov 22 '18 at 7:52
answered Nov 21 '18 at 15:17
noa-dev
1,85242149
1,85242149
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
|
show 1 more comment
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
|
show 1 more comment
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
"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