pyramid-react

[snario]

I'm not sure how feasible this would be but it would be nice if this was generalized to work on Pyramid too.

[markfinger]

Thanks for the reminder, I've been meaning to make the django dependency optional for a while. There's no great need for django, it's mostly legacy from the early projects where I was applying it.

Off the top of my head, django is being used for:

• the vendor version of six
• static file finders
• settings

None of them will be particularly difficult to excise, so once the the current wave of refactoring has settled, I'll take a stab at it.

[snario]

Sounds good, and thank you for replying so fast. :)

[markfinger]

@snario

Are there any conventions for configuring project settings in pyramid/flask/etc? In django projects, external apps such as django-react can easily read in your project's settings by importing django.conf.settings.

[snario]

@markfinger the equivalent in Pyramid is setup.py (or you can use the config.ini file)

http://docs.pylonsproject.org/projects/pyramid/en/master/narr/configuration.html#configuration-narr

http://docs.pylonsproject.org/projects/pyramid/en/master/quick_tutorial/ini.html

[markfinger]

Cool. Thanks for that, @snario

[snario]

@markfinger just curious, has there been any progress on this?

[markfinger]

Thanks for the reminder, @snario, I'd meant to update this.

Some parts of django-node have been excised into packages without a django dependency, but the services are taking a bit longer than I'd hoped, and they're what end up hosting most of the functionality. The plan is to deprecate django-node and replace its various functionalities with separate packages.

It's progressing, but given the number of layers involved, I've taken the opportunity to rethink the underlying structure and rewrite the low-level functionality, hence the delays.

The node/npm bindings have been rolled out into nodejs and npm, and they're feature complete. optional-django's slowly growing to handle the various conf, asset and rendering needs.

Regarding the services, still to do:

• write some python bindings to service-host - most of the codebase can probably be ripped straight out of django-node
• merge service-host and dev-service-host - this will probably be done in unison with writing the python bindings

Once a prototype of the service host is running, I can start porting django-webpack and django-react over to it and start decoupling them from django. :moneybag:

Probably another couple of weeks, but I'll let you know when I've got a prototype of the renderer working, if you're up for a bit of testing.

[mic159]

@snario I have a fork under https://github.com/mic159/react-render which has decoupled it from django. It is structured in a way where I can start adding other framework integrations (like pyramid, flask, etc.). It has react_render.core which is pure python, then react_render.django which is django specific. To add pyramid, it would be a matter of adding a react_render.pyramid wrapper.

The main difference between my fork and django-react, is that it has no dependencies on django-node, django-npm, etc. It does not try to hide the nodejs server inside django, you have to run it yourself separately. This makes it much more portable, where the python code pretty much just a call to requests.post().

[markfinger]

Took a while, but it's been decoupled without any loss of functionality :balloon: