- Use modern technology (React.js, TypeScript) without worrying about bloat or package count
- Use dependencies rather than reimplementing them manually
- Write cleaner CSS from scratch
- Solve some issues:
- Fetch i18n in separate request instead of bundling all languages together
- Improve overall DOM structure
- More organized updating of elements using React
- Add some features:
- Allow admin/moderation from comment section page (instead of just the admin panel)
- Use new
/config
endpoint for config -- remove client-side config
- A lot of places rely on the
config
object/instance. The config, however, needs to be fetched from the server first (or rather, the overrides). - The
api
needs to know its own endpoint, so it has to be instantiated or behave object-y, if we don't want to let it scrape the endpoint from script tags on every API invocation - Everything that translates things needs an
i18n
instance, which in turn needs to have aconfig
instance for language and pluralforms selection
I believe these are solved for the most part due to the nature of React:
- There are a lot of periodic tasks (updating
ago
datetime to human representation) to be done, all very similar. They should be handled in a "clock tick" fashion and not each run on their own (else we'd have asetTimeout
timer for each) They should vanish as soon as the underlying DOM object is gone. - The postbox and comment renderers can insert instances of each other, i.e. the a "comment" needs to be able to insert a postbox for replying and a postbox needs to insert comments once they're submitted.
- All template rendering needs a
config
and readily-configuredi18n
instance -
init()
andfetchComments()
both need to wait for the config to be fetched from the server. And they need a sort of locking/waiting mechanism to block until that is done, or defer those actions that rely on config until it is fetched. Also,init
needs to be able to tellfetchComments
to start working, so sharing some sort of mutex is needed.