Earlier quoted context omitted.
Why use a tool to solve a problem with another tool, rather than using tools that don't have the problem in the first place?
Because I decided I like React? :P From my perspective, React is the thing with the problem: it doesn't have great state management for complex tasks / multi-component coordination. What I want to use is something like RxJS to manage such interactions and state, because it gives me a lot of power/control in a relatively easy way. One of the best options out there that I've seen is redux-observable, and thus Redux its…
None of my projects want to be SPAs
231–240 of 362 posts
Re: None of my projects want to be SPAs
#232Earlier quoted context omitted.
> I have also witnessed discussions where management admits that they want something done in an SPA so that they can show that work to their investors, as a means of getting funding to do other projects. Absolutely. This extends well beyond SPAs, too, in my experience. I recently burned part of a month explaining to my senior management chain why you don't just, literally, "do machine learning." Of course, it turns o…
I do machine learning consulting and I see the flip side of this. I get new clients reaching out asking me to "add some AI" with no specific use cases in mind other than satisfying their investors that they are "leveraging AI."
Re: None of my projects want to be SPAs
#233Earlier quoted context omitted.
> The issue with Redux is that it encourages side effects in components. Which is why a lot of people that encourage Redux tend to also encourage one or more of the "side effect" managers such as thunks, sagas, or observables (my preference).
Why use a tool to solve a problem with another tool, rather than using tools that don't have the problem in the first place?
When I hear someone complaining about redux using global state, I like to ask them what makes global state bad. The answer is usually that it allows any part of the application to change a value, which makes debugging difficult. This doesn't apply to redux and similar frameworks because every slice of the state can only be managed by a single, pure function, which makes it incredibly easy to debug. Additionally, redux uses a copy on write mechanism, so your state tree isn't actually being mutated, which allows you to use equality comparison instead of a deep compare to see what state has changed. That, combined with the fact that all actions go through a central dispatcher that is easily audited means unit testing your state transitions is almost laughably trivial. And since you are pulling all of your business logic out of your UI components, you can avoid the side-effect hell of unit testing your UI.
Having said that, I won't use react or redux for any website that doesn't have a heavily interactive UI with complex state that must be shared across many pages. Managing application state in your front end is an enormous burden and you'd be crazy to take it on without a need for it.
Re: None of my projects want to be SPAs
#234Re: None of my projects want to be SPAs
#235Earlier quoted context omitted.
Building an SPA for every single project is like using a semi-trailer to commute everywhere you go. Sure, it will always get you where you need and sometimes turns have to be taken pretty wide, but what's the downside? Well, if you're destination is just 2 blocks down the road then why not walk? If you just need a simple page and the content doesn't need to be updated often, why not some flat HTML/CSS/JS? Many times…
I didn't consider small static sites. I agree with that and have done some landing pages that way that stand in front of SPAs. I guess I was commenting on OP wanting to use Rails or Spring MVC for views instead of only using them for APIs. I'm not sure what the term for it is, monolith maybe.
Re: None of my projects want to be SPAs
#236Earlier quoted context omitted.
I'm surprised you dislike Redux simply because it's a form of global state. Sure, global variables make debugging difficult when you don't know which function changed them where and when and why. But that doesn't happen if you keep your functions pure and only make changes from within reducers – at least that's my experience. (Boilerplate, yes, Redux adds that. But at least it's all in one place, and not scattered th…
> Sure, global variables make debugging difficult when you don't know which function changed them where and when and why. But that doesn't happen if you keep your functions pure and only make changes from within reducers – at least that's my experience. Sticking to reducers IS a good idea and it does make things a bit better. The problem with global state goes deeper than that, though. Often, as you learn about the s…
Re: None of my projects want to be SPAs
#237Earlier quoted context omitted.
> Sure, global variables make debugging difficult when you don't know which function changed them where and when and why. But that doesn't happen if you keep your functions pure and only make changes from within reducers – at least that's my experience. Sticking to reducers IS a good idea and it does make things a bit better. The problem with global state goes deeper than that, though. Often, as you learn about the s…
If you're giving me the choice between dealing with this: > Often, as you learn about the structure of the data, it becomes useful to change how the data is structured and stored. In global state, you can change that in reducers, sure, but then all the places that render that data have to be updated. You don't have the option to represent the same data in different ways that might be more suitable for different parts…
Futher, Redux doesn't solve synchronization issues in situations where you can't represent the data the same way. In the most complicated situations, it actually exacerbates the issue because it separates the data from the components that use it, making static analysis tools unable to see how your data changes might break the components. This also goes to show you didn't even understand the part of what I said that you selectively quoted, since I already said this.
> I'm not even hesitating before I choose the first option.
Perhaps if you hesitated a bit more, you could use that time to read all of the options and understand them.
Re: None of my projects want to be SPAs
#238Earlier quoted context omitted.
Infinite scroll, showing the details, clicking back sometimes doesn't bring me back to where I left off. Same when scrolling horizontally for example on the New releases I'll have to start scrolling right again after click on the details. Honestly, your website is probably the best implementation of a SPA website with multiple pages I have ever seen I can recollect. It still has quirks though. I just don't see why yo…
Hey, that's super helpful, thanks! Why SPA? Well, a good question indeed. Actually, we're cross-compiling the same code for the webapp onto iOS and Android targets with build flags, where we're leveraging more platform features (i.e. geolocate cinemas). Also, it lets us make the experience itself much more snappy once you're on the page, as there's just content to be re-loaded. You can switch tabs, we can remember sc…
Nothing can possibli go wrong
Re: None of my projects want to be SPAs
#239We recently went in the opposite direction for a student project I'm working. We have a full SPA Angular frontend, and we use CouchDB as our datastore. There is a Node "backend," but it only serves things like Slack integration, the browser has a local PouchDB instance that directly syncs with the server's CouchDB. This way, we can deploy hotspots with nothing more than a Couch install and a static server for the SPA…
Are you running your own CouchDB instance?
Re: None of my projects want to be SPAs
#240Earlier quoted context omitted.
You have information which has global nature, used in multiple sorts of the application. This could be, among other things - STDIN/STDOUT/STDERR file handles - static configuration - some parts of runtime configuration - application info (in a game maybe current score, current level, active players, ...) All that information exists only once and is needed in many parts.
>exists only once and is needed in many parts. I think many people could argue that this concept itself is a bit misguided. There are plenty of application patterns and architectures that help you move stateful data around your app and translate it for the components who need to consume it or change it, while hiding it from components in the tree which do not interact with or care about the state. If you have many di…