Incoming links: React
React setups:
One problem with Django is that it does not expose its ORM as an external library: stackoverflow.com/questions/33170016/how-to-use-django-1-8-5-orm-without-creating-a-django-project which is wasteful of development time.
@cirosantilli/_file/nodejs/next/nodejs/next/inject-into-static Updated 2025-03-28 +Created 2024-08-27
In this example we attempt to inject React elements into statically rendered HTML coming from the server, and properly hydrate them.
Questions by Ciro Santilli:
The goal of this example is to understand when states and effects happen when changing between different routes that use the same component.
Behavior is follows:
- visit: localhost:3001/1
- click
count++. This makescount: 1 - click "2" to visit localhost:3001/2
- outcome: count is still 1
This is likely because in React the state kept in the virtual DOM structure, and identical structure implies identical state. So when we change from post 1 to 2, we still have a
Post object, and state is unchanged.Next if we click:then the count is back to 0. This is because we changed the
- "Index" to go to localhost:3000
- "1" to go to localhost:3001/1
Post object in the DOM to Index and back, which resets everything.This example also illustrates how to prevent this from happening with
useEffect.This is a minimal reproducible example for the terrible problem of external effects applying twice to refs for effects that are not idempotent and thus blowup if applied twice.
The issue is currently discussed at: react.dev/learn/synchronizing-with-effects#step-3-add-cleanup-if-needed (archive) which says "you need to cleanup the thing yourself". web.archive.org/web/20240720100401/https://react.dev/learn/synchronizing-with-effects#subscribing-to-events is also says that for the specific case of
addEventListener.But that's annoying! Can't we just somehow tell if we applied twice or not to avoid having to implement a cleanup? What if a third party system does not provide a cleanup at all?
Is the correct solution to just just have a
useEffect with empty dependency list? Seems to be good according to posts and to ESLint!Tried to do a React only reproduction at: react/ref-twice.html.
Bibliography:
Ciro Santilli's implementation: node Express Sequelize Next.js realworld example app.
Ahh, you can't have new ideas anymore!
Basically puts together every backend with Front-end web framework to create the exact same website.
The reference live demo can be found at: demo.realworld.io/#/ It is based on Angular.js as it links to: github.com/gothinkster/angularjs-realworld-example-app TODO backend?
There are however also live demos of other frontends, e.g.:Note that all those frontends communicate with the same backend.
- React: react-redux.realworld.io. But note that tag addition at post creation is broken there as of March 2021, but not on master: github.com/gothinkster/react-redux-realworld-example-app/issues/151#issuecomment-808417846 so they forgot to update the live server.
- Vue.js: vue-vuex-realworld.netlify.app
As of 2021 Devs are seemed a bit too focused on monetizing the project through their "how to use this project" premium tutorial, and documentation could be better: just getting the hello world of the most popular backend with the most popular frontend is not easy... come on.
github.com/gothinkster/realworld/issues/578 asks for community support, as devs have moved on since unfortunately.
Remember:
- by default, the frontends hardcode the upstream public data API:
https://conduit.productionready.io/apiso you have to hack their code to match the port of the backend. And each backend can have a different port. - when you switch between backends, you must first manually clear client-side storage cookies/local new run will fail due to authentication issues!
Important missing things from the minimum base app:
- server-side rendering:
- github.com/arrlancore/nextjs-ssr-real-world-app-example. As advertised, that global instance does render with JavaScript disabled! Proposed for upstream at: github.com/gothinkster/realworld/issues/423
- github.com/gothinkster/realworld/issues/266
- no javaScript bi-directional communication library built-in... come on: github.com/gothinkster/realworld/issues/107
- email notifications however as tested on the live demo: demo.realworld.io/#/
- error handling is broken/missing/inconsistent across apps
First you should the most popular backend/frontend combination running, which is the most likely to be working. We managed to run on Ubuntu 20.10, React + Node.js Express.js as described at github.com/gothinkster/node-express-realworld-example-app/pull/116:Then just:on both server and client, and then visit the client URL: localhost:4100/
- github.com/cirosantilli/node-express-realworld-example-app/tree/mongo4 which has a simple patch on top of github.com/gothinkster/node-express-realworld-example-app/tree/ba04b70c31af81ca7935096740a6e083563b3a4a for MongoDB 4 supportThis requires you to first install MongoDB on Ubuntu and ensure you can login to it from the command line.
- github.com/gothinkster/react-redux-realworld-example-app/tree/9186292054dc37567e707602a15a0884d6bdae35 patched to use the correct server host/port
localhost:3000:diff --git a/src/agent.js b/src/agent.js index adfbd72..e3cdc7f 100644 --- a/src/agent.js +++ b/src/agent.js @@ -3,7 +3,7 @@ import _superagent from 'superagent'; const superagent = superagentPromise(_superagent, global.Promise); -const API_ROOT = 'https://conduit.productionready.io/api'; +const API_ROOT = 'http://localhost:3030/api'; const encode = encodeURIComponent; const responseBody = res => res.body;
npm install
npm startYou have to hit the Enter key to add tags, it's terrible: github.com/gothinkster/react-redux-realworld-example-app/issues/151#issuecomment-808417846
One cool thing is that the main repo has unified backend API tests:so the per-repository tests are basically useless, and that single test can test everything for any backend! There is no frontend testing however: github.com/gothinkster/realworld/issues/269 so newb.
git clone https://github.com/gothinkster/realworld
cd realworld
git checkout e7adc6b06b459e578d7d4a6738c1c050598ba431
cd api
APIURL=http://localhost:3000/api USERNAME="u$(date +%s)" ./run-api-tests.shSetups we've tried:
- backend:
- randyscotsmithey/feathers-realworld-example-app worked with React and Vue.js
- the React setup failed as shown at: github.com/gothinkster/react-redux-realworld-example-app/issues/187
- gothinkster/django-realworld-example-app
- the Nest.js failed on Ubuntu 20.10 as per github.com/lujakob/nestjs-realworld-example-app/issues/19
- frontend:
The idea is cool. It really unifies front-and back end.
But Ciro Santilli feels the approach proposed by FeathersJS of being a glue between bigger third-party Front-end web frameworks like React and backend (object-relational mapping) is more promising and flexible.
FeathersJS entry for gothinkster/realworld.
MongoDB-based.
So once you install MongoDB, run with:
MONGODB_FEATHERS_REALWORLD=mongodb://localhost:27017/mydb npm startGot it working on Ubuntu 20.10 with both React and Vue.js front-ends at github.com/randyscotsmithey/feathers-realworld-example-app/commit/8bc3a09242285de624c75bb8345630df499a7d07 as mentioned at github.com/randyscotsmithey/feathers-realworld-example-app/issues/2 except for bad error reporting on UI.
Tests can be run with:but there were 10 failures and 55 passes: github.com/randyscotsmithey/feathers-realworld-example-app/issues/3
MONGODB_FEATHERS_REALWORLD=mongodb://localhost:27017/mydb npm run testIntegrations React integration:
- github.com/shakacode/react_on_rails: webpack and server-side rendering
- github.com/reactjs/react-rails Official on the React side only. Demo app linked from package: github.com/BookOfGreg/react-rails-example-app and how it fails: github.com/BookOfGreg/react-rails-example-app/issues/30... The related projects section has some good links:
- shakacode/react_on_rails
- github.com/hyperstack-org/hyperstack transpiles Ruby to JavaScript + React. What could possibly go wrong? :-)
Front-end web framework integration: no native one:
- React:
- Vue.js:
- github.com/mikermcneil/ration Issue tracker disabled...
- live at: ration.io/
- selling a course at: courses.platzi.com/courses/sails-js/
- platzi.com/cursos/javascript-pro/ non-free and in Spanish pointed to from official README...
- Nuxt.js:
- github.com/mikermcneil/ration Issue tracker disabled...
TODO server-side rendering anyone??
- stackoverflow.com/questions/32412590/how-to-use-react-js-to-render-server-side-template-on-sails-js
- stackoverflow.com/questions/54217147/ssr-for-react-redux-application-with-sails
- gist.github.com/duffpod/746a660bcddfd986878c92dde1a04f06
- www.reddit.com/r/reactjs/comments/7saoqm/sailsjs_or_adonisjs_designed_for_server_side/
In any case, the outcome of that is that the tech has improved. And I have done a relatively good job of clearly publishing any "more user visible" improvements to docs.ourbigbook.com/news and social media such as though it is important to note that there have been more than one "fix a hard bug" weeks that were not published because they would just bore readers.
During this period the main focus has been on improving OurBigBook Web, i.e. the dynamic website that powers OurBigBook.com. There are two reasons for that:As a result, Web is now way less buggy and much more usable.
- Web is what has the OurBigBook topics feature for mind-melding, which is the killer feature of OurBigBook compared to other note taking apps and therefore deserves the highest levels of priorityStatic website generation is an indispensable escape valve that ensures that your content can be published forever even if OurBigBook.com goes down one day, which it won't as long as I live. But the innovation is Web.
- static website generation was closer to good enough, but web was much further and is fundamentally harder.I'm extremely satisfied with OurBigBook static website generation and haven't touched it as much. It wasn't easy to reach this state, but I'm there.But Web is a different and much more complex beast.Making CLI software that will run on a person's local computer under full trust and building a bunch of HTML from lightweight markup in bulk is one thing.But making a public dynamic website that has to continuously maintain a coherent database state on granular updates, while giving users some trust but not enough for them to blow everything up is on a totally different level. See e.g. the recent SPAM attack we've had to fend off.
Figure 1. Screenshot showing voting manipulated SPAM as the most highly upvoted article on OurBigBook.com. Source.And then there's also the issue of front-end being mega-hard to get right.
If you look through the list of Web updates, there is nothing specifically mind blowing. The core ideas have largely crystallized, and we are just trying to making them click. I have a few more punches up my sleeve, but the core is decided.
OurBigBook Web search
. Source. This is one of the many basic quality of life improvements that have been done on OurBigBook Web.
OurBigBook Web article announcement
. Source. Another cute new feature, you can send an email to your followers about a new amazing article you created.Web process has been somewhat slower than what I'd like. Of course, it is the case of any project that things are easily said than done. But there are two other main structural factors that have played into it:
- I have my first baby now, and we're learning how to deal with that on the fly.For example, we could have put him on childcare a bit earlier, but due to inexperience we've kept him a bit longer than we maybe should have.Things are well sorted out now, but not matter how good your support system is, at the end of the day, and more often night, it is you the parents that have to deal with a lot of inevitable baby issues. Unless you want them to turn into psychopaths and drug addicts that is, which I don't. I've reached the point of semi failure middle age that the baby feels like my best moonshot.All of this sets a fundamental limit on how many hours you can work per week.But at least with the donations I was able to work on OurBigBook at all. Because if it weren't for that, I would have to focus entirely on the generic job instead and OurBigBook would have been put on hold.
- the choice of Web stack. I was allured by Next.js. I can see the beauty and usefulness of a Node.js render front-end that also runs on backend and hydration. That is awesome.But:
- React is insanely hard to learn and understand. Furthermore, it is also hard to understand the performance problem that it solves, and actually have a benchmark where this problem is solved faster than just delivering some HTML files with ad-hoc Js on top.
- the lack (or perhaps excess of shitty) actual web framework like Ruby on Rails and Django means that I have to rediscover the wheel many times over for all the essential support activities like testing, login and so one
At this point a rewrite is out of the question. I've managed to master things well enough to get a decent result, and given up on the few things that I couldn't for the life of me achieve, after documenting them very well for posterity of course.
Aside from Web, there was only one thing that received a significant improvement, and that was the OurBigBook VS Code extension. The extension is not perfect, and it is not the "final UI", which has to be some WYSIWYG implementation, and there are some fundamental limitations that cannot be overcome without patching VS Code itself. However, the extension is already extremely usable, and I'm writing this on it right now. Basics like syntax highlighting, jump to definition and autocomplete are very useful and usable.
Tree navigation in the OurBigBook Visual Studio Code extension
. This should only be used for things that happen outside of the state that React trackes, e.g.
window event handlers.Examples: