4 ms·

I don't consider reducers, actions, redux/flux to be React specific, even if they are popular in the React world. I know just as many people who don't use those

I don't consider reducers, actions, redux/flux to be React specific, even if they are popular in the React world. I know just as many people who don't use those in the React world. IMO what React did was push forward the single data flow paradigm. What should a developer do that needs to share state across a Forgo app? It would be awesome if browsers just had a real template language like JSX, we'd see more "web components" which are just a little bit of JSX/or whatever templates and some DOM APIs. Developers are tired of managing binding and unbinding events. React does that well. I assume Fargo does too. So putting aside the redux/flux paradigm, what else is the real hurdle being solved?

jeswin 6y ago
> What should a developer do that needs to share state across a Forgo app? We already have many facilities in JS to handle state. Singleton patterns, closures etc. The example on the website uses closures to handle component state - which is simpler than React's hooks based approach. function SimpleTimer() { let seconds = 0; // Just a plain variable return { render(props, args) { setTimeout(() => { seconds++; rerender(args.element); // rerender! }, 1000); return <div>{seconds} secs have elapsed...</div>; }, }; } > I don't consider reducers, actions, redux/flux to be React specific They didn't emerge from React - but it isn't possible to do React without them. When I conduct trainings, I often see some of my students go - wow, why would you do that? So Forgo basically is an exploration of how to simplify things - and to let users pick their desired level of complexity.
- dceddia 6y ago
  I understand where the Redux terminology gets mixed up with React and people believe they're one and the same, but it's totally possible to do React without touching reducers, actions, or Redux. Maybe you mean it's not realistic to write React "beyond toy examples" or "in the real world" without Redux, but still, I'd beg to differ there. You can get very far with plain React and the context API and other libraries. Redux definitely isn't required. Forgo does look cool though! I like the idea of using plain variables for state, and returning an object allows you to add other things to that object (didMount, didUpdate, unmount etc).
  - michaelpb 6y ago
    Yeah, even with large-ish projects, just by refactoring some of your state manipulation into separate libraries that you manually hook into your top-level components, you can get by quite fine without a whiff of Redux. That said, this is a cool framework, congrats on completing it! I'm also working on a minimalist React-ish framework though in a very different approach.
- chrisabrams 6y ago
  > They didn't emerge from React - but it isn't possible to do React without them. It is 100% possible to build large React apps without redux/flux. There are entire ecosystems built around, say Mobx, among many other libraries and tools which don't even follow the flux style patterns. > The example on the website uses closures to handle component state I'm not asking about component state; I'm asking how do multiple components access app-wide state. I can't use a singleton for that; how do I know when that singleton is updated? I guess I could use a proxy but I don't want to do that. > and to let users pick their desired level of complexity. React is the view layer. It doesn't enforce any type of data layer or state management layer.
  - jeswin 6y ago
    > I can't use a singleton for that; how do I know when that singleton is updated? It's up to the developer to make that decision. An AccountInfo control could be listening to "ACCOUNT_INFO_CHANGE" events (emitted when account info changes), and can subsequently rerender and read off some singleton state. Rerenders are explicit. And like you said, proxies could be another option.
  - deleted 6y ago
    [deleted]
- chrisabrams 6y ago
  > They didn't emerge from React - but it isn't possible to do React without them. Here is a React/WebGL game I made which tracks a lot of variables and state, but does not use redux/flux...because it's 100% possible to make even make a 3D game with React without them!!! https://focused-ritchie-7245d6.netlify.app/ https://focused-ritchie-7245d6.netlify.app/
- lhorie 6y ago
  > The example on the website uses closures to handle component state This looks a lot like closure components from Mithril.js[0], which have been around for several years. It's nice to see people independently come to the conclusion that this approach is simpler :) [0] https://mithril.js.org/components.html#closure-component-state https://mithril.js.org/components.html#closure-component-sta...
  - jeswin 6y ago
    Thanks, hadn't seen this prior art!
- resynth1943 6y ago
  > They didn't emerge from React - but it isn't possible to do React without them. I've created many React apps without any complex state management libraries :-)
spankalee 6y ago
I work on a templating library called lit-html that aims to just solve the declarative DOM w/ property & events bindings problem: https://lit-html.polymer-project.org/ https://lit-html.polymer-project.org/ It's plain JS with a very similar DX to JSX, and I think addresses that really well. My team also works closely with Chrome, Safari, and Firefox on proposals like Template Instantiation that aim to build up more APIs that template libraries can use to be smaller, faster, and more interoperable. I really think we will eventually get good templating in the DOM so at least the most common use-cases are taken care of.
- no_wizard 6y ago
  Where is the working group at with that proposal? I've been eyeing it closely, but it hasn't seen any significant movement in over two years, last I checked. I'm excited about template instantiate, though I worry the API is going to be tied to having template element instances, instead of being part of the HTMLTemplateElement and its own thing I could take advantage of with string templates. I also haven't seen any place where I can give feedback formally on the proposal to the working group :( HTML imports were supposed to be the holy grail to solve this, but nobody but Chrome supported it :(
  - spankalee 6y ago
    It's being discussed mainly in the WICG web components GitHub repo. There are recent issues in here: https://github.com/WICG/webcomponents/issues https://github.com/WICG/webcomponents/issues
- eyelidlessness 6y ago
  Every time I look at lit I get this unsettling feeling that it’s almost what I want but can’t be, because it loses the only thing I want in JSX. Lit fundamentally targets templates with HTML output. Which is great for what it is. But the thing JSX offers that nothing else does is: - return values are a data structure, so they’re render-target/render-implementation agnostic - it’s compile time only/effectively a macro, so the compiler can choose how to render subtrees I love the “it’s actually part of the language not a build tool” part of lit, but it can’t satisfy those other goals without giving up its core selling points.

jeswin 6y ago

> What should a developer do that needs to share state across a Forgo app? We already have many facilities in JS to handle state. Singleton patterns, closures etc. The example on the website uses closures to handle component state - which is simpler than React's hooks based approach. function SimpleTimer() { let seconds = 0; // Just a plain variable return { render(props, args) { setTimeout(() => { seconds++; rerender(args.element); // rerender! }, 1000); return <div>{seconds} secs have elapsed...</div>; }, }; } > I don't consider reducers, actions, redux/flux to be React specific They didn't emerge from React - but it isn't possible to do React without them. When I conduct trainings, I often see some of my students go - wow, why would you do that? So Forgo basically is an exploration of how to simplify things - and to let users pick their desired level of complexity.

dceddia 6y ago
I understand where the Redux terminology gets mixed up with React and people believe they're one and the same, but it's totally possible to do React without touching reducers, actions, or Redux. Maybe you mean it's not realistic to write React "beyond toy examples" or "in the real world" without Redux, but still, I'd beg to differ there. You can get very far with plain React and the context API and other libraries. Redux definitely isn't required. Forgo does look cool though! I like the idea of using plain variables for state, and returning an object allows you to add other things to that object (didMount, didUpdate, unmount etc).
- michaelpb 6y ago
  Yeah, even with large-ish projects, just by refactoring some of your state manipulation into separate libraries that you manually hook into your top-level components, you can get by quite fine without a whiff of Redux. That said, this is a cool framework, congrats on completing it! I'm also working on a minimalist React-ish framework though in a very different approach.
chrisabrams 6y ago
> They didn't emerge from React - but it isn't possible to do React without them. It is 100% possible to build large React apps without redux/flux. There are entire ecosystems built around, say Mobx, among many other libraries and tools which don't even follow the flux style patterns. > The example on the website uses closures to handle component state I'm not asking about component state; I'm asking how do multiple components access app-wide state. I can't use a singleton for that; how do I know when that singleton is updated? I guess I could use a proxy but I don't want to do that. > and to let users pick their desired level of complexity. React is the view layer. It doesn't enforce any type of data layer or state management layer.
- jeswin 6y ago
  > I can't use a singleton for that; how do I know when that singleton is updated? It's up to the developer to make that decision. An AccountInfo control could be listening to "ACCOUNT_INFO_CHANGE" events (emitted when account info changes), and can subsequently rerender and read off some singleton state. Rerenders are explicit. And like you said, proxies could be another option.
- deleted 6y ago
  [deleted]
chrisabrams 6y ago
> They didn't emerge from React - but it isn't possible to do React without them. Here is a React/WebGL game I made which tracks a lot of variables and state, but does not use redux/flux...because it's 100% possible to make even make a 3D game with React without them!!! https://focused-ritchie-7245d6.netlify.app/ https://focused-ritchie-7245d6.netlify.app/
lhorie 6y ago
> The example on the website uses closures to handle component state This looks a lot like closure components from Mithril.js[0], which have been around for several years. It's nice to see people independently come to the conclusion that this approach is simpler :) [0] https://mithril.js.org/components.html#closure-component-state https://mithril.js.org/components.html#closure-component-sta...
- jeswin 6y ago
  Thanks, hadn't seen this prior art!
resynth1943 6y ago
> They didn't emerge from React - but it isn't possible to do React without them. I've created many React apps without any complex state management libraries :-)

spankalee 6y ago

I work on a templating library called lit-html that aims to just solve the declarative DOM w/ property & events bindings problem: https://lit-html.polymer-project.org/ https://lit-html.polymer-project.org/ It's plain JS with a very similar DX to JSX, and I think addresses that really well. My team also works closely with Chrome, Safari, and Firefox on proposals like Template Instantiation that aim to build up more APIs that template libraries can use to be smaller, faster, and more interoperable. I really think we will eventually get good templating in the DOM so at least the most common use-cases are taken care of.

no_wizard 6y ago
Where is the working group at with that proposal? I've been eyeing it closely, but it hasn't seen any significant movement in over two years, last I checked. I'm excited about template instantiate, though I worry the API is going to be tied to having template element instances, instead of being part of the HTMLTemplateElement and its own thing I could take advantage of with string templates. I also haven't seen any place where I can give feedback formally on the proposal to the working group :( HTML imports were supposed to be the holy grail to solve this, but nobody but Chrome supported it :(
- spankalee 6y ago
  It's being discussed mainly in the WICG web components GitHub repo. There are recent issues in here: https://github.com/WICG/webcomponents/issues https://github.com/WICG/webcomponents/issues
eyelidlessness 6y ago
Every time I look at lit I get this unsettling feeling that it’s almost what I want but can’t be, because it loses the only thing I want in JSX. Lit fundamentally targets templates with HTML output. Which is great for what it is. But the thing JSX offers that nothing else does is: - return values are a data structure, so they’re render-target/render-implementation agnostic - it’s compile time only/effectively a macro, so the compiler can choose how to render subtrees I love the “it’s actually part of the language not a build tool” part of lit, but it can’t satisfy those other goals without giving up its core selling points.