If you're gonna use React Router and Redux, you should also check out react-router-redux: https://github.com/reactjs/react-router-redux
This is exactly what I'm talking about though, how many different libraries are there for routing alone? How can anyone make a reasonably informed choice between them? It's madness!
My heuristic is:
1. Google for a blog comparing them, and eliminate any candidates with major red flags
2. Go with the one that has the most stars on it's github repo.
If you're gonna use React Router and Redux, you should also check out react-router-redux: https://github.com/reactjs/react-router-redux
This is exactly what I'm talking about though, how many different libraries are there for routing alone? How can anyone make a reasonably informed choice between them? It's madness!
Picking out libraries, to some developers I work with, has become the same as shopping for a TV as Best Buy. They try to get the one with the bestest of everything, and just end up with a POS that no one wants to watch TV on.
What can ya do? This is where we find ourselves today. It's a mess. But what if I told you there was another way...?
If you're gonna use React Router and Redux, you should also check out react-router-redux: https://github.com/reactjs/react-router-redux
This is exactly what I'm talking about though, how many different libraries are there for routing alone? How can anyone make a reasonably informed choice between them? It's madness!
See if others are using it, read the documentation, read the issues list, and/or read the source code. React-router-redux only has 216 lines of code! (Not counting tests, etc.)
I'd like to know the answer to this too. What I've thought so far is that I just call the function that makes db calls or other operation on the server side but this is clearly not the way do in client side if the app was to be universal.
In my experience [1], you'd probably just use an if statement that does something different when you're on the server. That's totally fine and is still a universal app; universal apps don't have to take every exact same code path on the client and server, they just have to run the same code base. In React, people typically use the ExecutionEnvironment module [2] for this: if (ExecutionEnvironment.canUseDOM) { // make…
I'm actually working on an isomorphic app. My approach is to simply create a PersistenceService interface, with methods returning promises, and to make two classes implementing it, SqlPersistenceService and AjaxPersistenceService. You inject the correct instance when you create the server and when you create the client. No if needed, and as I'm using Typescript, the compiler ensures both SqlPersistenceService and AjaxPersistenceService will keep following the contract of PersistenceService in the future.
What I'd like to be able to do is not incur an additional HTTP request against my own server. Does SuperAgent have a way to avoid opening a new socket when making a request against yourself?
Yeah, I understood what you wanted. I may not have been clear in my line of thinking. My understanding is that react-server does not support this. However, I do not believe that it would be difficult to add support using the testing plugins built for SuperAgent. Imagine writing tests with mocked requests. Now apply that same logic to all calls to fetch() on the server. Does that make sense? So to the front end when f…
I'm totally on board with the "contributions welcome" response from open source maintainers, but when it's the only response to questions about documentation it's pretty off-putting. This is your project, how could you expect a new contributor to add docs without your input? I get that good documentation is hard, and takes time, but if you want your project to succeed I think it's almost mandatory for you to write th…
I have to agree here. There's nobody better to explain how something really works than the person who wrote it. The rest of us are just fumbling around guessing. As a dev and a creative person, I understand the desire to get something out there. But documentation and tutorials aren't just something that's nice to have. They are your marketing tool, your adoption driver, and the way to create educated advocates for yo…
To me this product markets itself. This team has accomplished a lot with this tool, and i'm compelled to adopt and educate myself.
The proof (and splash) is in the pudding here. Kudos to dev team that built this.
This is exactly what I'm talking about though, how many different libraries are there for routing alone? How can anyone make a reasonably informed choice between them? It's madness!
Picking out libraries, to some developers I work with, has become the same as shopping for a TV as Best Buy. They try to get the one with the bestest of everything, and just end up with a POS that no one wants to watch TV on. What can ya do? This is where we find ourselves today. It's a mess. But what if I told you there was another way...?
Humorously this looks a bit like Apache Wicket, a Java-based client/server UI framework which has been around for about 10 years: https://wicket.apache.org