re-frame VS django-extensions

This article always reminds me of this excerpt from re-frame’s docs [0]:

> Now, you think and design abstractly for a living, and that repetition will feel uncomfortable. It will call to you like a Siren: "refaaaaactoooor meeeee". "Maaaake it DRYYYY". So here's my tip: tie yourself to the mast and sail on. That repetition is good. It is serving a purpose. Just sail on.

[0]: https://github.com/day8/re-frame/blob/master/docs/correcting...

* Single-Page App: shadow-cljs for the build concerns (https://github.com/thheller/shadow-cljs), Reagent with Re-frame for complex/large app (https://reagent-project.github.io and https://github.com/day8/re-frame). Even if we now prefer using HTMX (https://htmx.org) and server-side rendering (Hiccup way of manipulating HTML is just amazing, https://github.com/weavejester/hiccup).

Big and/or complete projects that use re-frame The main list: https://github.com/day8/re-frame/blob/master/docs/External-Resources.md

Reflet is a set of tools for building Re-frame + React based web apps with graph and non-graph data models. This includes:

https://github.com/day8/re-frame

Notably the author of re-frame has been weary of hooks.

I think that’s for a good reason. The approach in re frame feels like the best way to manage state so far for a react based app. Everything that changes state flows through an event. State can only be observed through subscriptions. Side effects are isolated to their own type of event. Debugging and testing are so straight forward with these concepts.

Redux got close but it has two problems in my mind. Like hooks, it encapsulates for no good reason. Put the state in one thing that you can observe holistically before and after pure events. It also has too much boiler plate.

The cljs stack I hear about a lot (and use) is ShadowCLJS with reagent (https://reagent-project.github.io/) and re-frame (https://day8.github.io/re-frame/). ShadowCLJS is more of a build tool, but is really well documented and easy to use. Reagent is basically react but a simpler API, and re-frame is a layer on top of that provides data subscriptions and event-handlers to manage app state. It's overkill for some apps but I find it's actually super easy to work with and not as much complexity as I thought.

For backend there is luminus (https://luminusweb.com/) or Kit (https://kit-clj.github.io/). They are basically project templates that wire together a ton of popular solutions for various things - database access, migrations, security, html templating, etc. Also includes frontend frameworks like re-frame if you want.

Reflet aims to be a natural progression on top of Re-frame to support complex, data driven requirements. In that sense, it is both easy to learn, but powerful. You could say it's sort of like Re-frame++ (or Fulcro for Re-frame). Its main design goals are:

At my current client we're working on having a frontend architecture for writing SPAs in JavaScript similar to re-frame's one: an event-driven bus with effects and coeffects for state management[1] (commands) and subscriptions using reselect's selectors (queries).

Some of us had worked with effects and coeffects before while developing SPAs with re-frame and had experienced how good it is. After working with re-frame, when you come to horizon, you realize how a good architecture can make a dramatic difference in clarity, testability, understandability and easiness of change.

https://youtu.be/geeK1-jjlhY (talk about an initial prototype with re-frame and the decision to do a rewrite in Clojure)

django_extensions/utils/dia2django.py: https://github.com/django-extensions/django-extensions/blob/...

django_extensions/management/modelviz.py:

I often perform operational tasks such as modifying data or debugging failures using the Django shell. In fact, anything I can't do through the admin or through management commands I use the shell for. The package django-extensions provides a shell on steroids that I much prefer over the built in shell. It allows you to run a custom REPL such as IPython or Ptpython and has autocomplete, command history, automatic model class imports and a myriad of other dev tools. shell_plus is for a Django programmer what a scalpel is for a surgeon.

It currently has a bug with the latest django update I think; so if it it isn't fixed by the time you try it, remember to check it out later, because django-extensions is genuinely useful.

alias m='exit_if_not_in_python_virtual_env && ./manage.py' alias mcs='exit_if_not_in_python_virtual_env && ./manage.py collectstatic' alias mcsu='exit_if_not_in_python_virtual_env && ./manage.py createsuperuser' alias mm='exit_if_not_in_python_virtual_env && ./manage.py migrate' alias mmm='exit_if_not_in_python_virtual_env && ./manage.py makemigrations' alias mrs='exit_if_not_in_python_virtual_env && ./manage.py runserver' alias ms='exit_if_not_in_python_virtual_env && ./manage.py shell' alias msa='exit_if_not_in_python_virtual_env && ./manage.py startapp' alias mt='exit_if_not_in_python_virtual_env && ./manage.py test' alias mts='exit_if_not_in_python_virtual_env && ./manage.py testserver' # [django-extension](https://github.com/django-extensions/django-extensions): alias msu="exit_if_not_in_python_virtual_env && ./manage.py show_urls" alias mvt="exit_if_not_in_python_virtual_env && ./manage.py validate_templates" alias msp="exit_if_not_in_python_virtual_env && ./manage.py shell_plus" alias mrsp="exit_if_not_in_python_virtual_env && ./manage.py runserver_plus"

I use https://github.com/django-extensions/django-extensions

If you just want a list of all the available urls & paths in your app, take a look at the django-extensions package. It has a django management command show_urls, which will list them all out nicely.

https://github.com/django-extensions/django-extensions has a command, show_urls which outputs the URLs rendered for a project along with the name of their view handler

# 1 million lines of logic and who knows how many queries

I've actually seen this pattern in every Django project :(

Regarding urls, instead of enforcing a flat file, I'd highly recommend always using django_extensions[0]. You'll get `shell_plus` that auto imports model and `show_urls` that you can grep for endpoint and gives you the handler.

[0] https://github.com/django-extensions/django-extensions

A common mistake in django is to make a model change but forget to run makemigrations to generate a migration for the model change. Sometimes it is not entirely obvious when this need to happen. For example, let's say I'm using the django-extensions library and I define a model like:

Django Extensions has a shell_plus with notebook mode.