Define public API

[JuroOravec]

Currently it's not entirely clear what interfaces (files/variables) are part of public API. Before v1.0, it would be also good to clear this up, so we know which things we can change internally, and which need to be maintained.

This project also doesn't have very big surface area, so I think that for now it could be sufficient to expose the "public" parts via src/__init__.py, so it can be imported as

from django_components import bla_bla

The exception to the above are middleware and template tags, which can be used in Django settings and referenced via filepath (e.g. "django_components.templatetags.component_tags"

[EmilStenstrom]

Before deciding on how to expose the public API, let's just start by listing out all the concepts that we expect people to understand to use components in their projects:

• The component template tag, the slot and fill tags (with all their options and parameters, how they nest and how they interplay with extends, blocks, defaults, reusing content and so on)
• Management commands to create and upgrade components
• Installed app to make py files in staticfiles safe again
• Middleware to make components load dynamically
• Installed app to load the library
• Directory structure you need for a component
• Components registry, and the register function
• Component class, its methods that you override, it's class variables that you config
• The Media metaclass where you define your CSS
• How template autodiscovery works or how you automatically load your components
• component_dependencies, component_js_dependencies, component_css_dependencies
• Single file components, and the custom types that we define
• How to call a component as a view
• Render_to_response helper method, with the escape_slots_content param
• component_vars.is_filled and it's subkeys
• The COMPONENTS setting dict and all it's keys

Anything else?