Skip to content

Reconsider how we use/advertise idom.run() #657

Closed
@Archmonger

Description

@Archmonger

Current Situation

idom.run() probably shouldn't be the primary advertised way of using IDOM. Especially in it's current state.

Using a development webserver for production use is a big no-no, and by prominently displaying idom.run() as the first steps to using IDOM shows we are encouraging people to do just that. I believe the primary way of utilizing IDOM should be embedding within existing applications.

Proposed Actions

  • Keep idom.run() as is, but add logging to indicate idom.run() is not suited for production use.
    • ex. idom.run() is only intended for testing purposes. For production use, consider embedding IDOM within an existing project. Check out the docs for more info.
  • Expand the ease-of-use for integrating into supported web frameworks, similar to Django-IDOM
  • Remove SharedClientState, as it is not compatible with multiprocessed webservers.
    • This is also an opportunity to rename PerClientState to IdomView

Optional

  • Change the callable name/path to more appropriately indicate danger or for testing purposes only
    • idom.testing.webserver()
    • idom.shortcuts.run()
    • idom.devtools.run_webserver()
  • Remove the pip parameter for frameworks (it's really not needed)
    • idom.run() should raise a simple to understand exception if the user has forgotten to install a web framework
    • ex. Looks like you don't have a web framework installed. You'll need to pip install one of the following: fastapi, flask, sanic

Metadata

Metadata

Assignees

No one assigned

    Labels

    priority-3-lowMay be resolved one any timeline.type-docsAbout changes and updates to documentationtype-revisionAbout a change in functionality or behavior

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions