search

widgetti / ipyreact

React for ipywidgets that just works. No webpack, no npm, no hassle
BSD 3-Clause "New" or "Revised" License
119 stars 8 forks source link

Thoughts on building esm at python packaging time #71

Open paddymul opened 6 days ago

paddymul commented 6 days ago

What are your thoughts on a pattern like this?

In the future, when I care about bundle sizes of my widget, I would prefer not to ship sucrase in the bundled JS. My _esm cproperties are very small, essentially shims between my component library and ipyreact. What would it look like if there was no sucrase shipped with js bundle. (I'm not worried about the time it takes to execute sucrase, this should be minimal.

What if the _esm blocks were hashed and compiled in a step. Then there was a shipped dictionary from _esm_hash to compiled js. The frontend code references this dictionary in production mode, and the 1mb sucrase dependency doesn't ship.

This is a pretty advanced optimization that I don't think I'll get to for a while, if ever. but curious on your thoughts

paddymul commented 6 days ago

As I think about it, I'm trying to figure out if I will need to fork ipyreact to suit my needs. I'd prefer not to. I'm just thinking about plans for my roadmap.

Here are the things I'd like to do which would require js changes to ipyreact

  1. Easier CSS importing. Nice to have. I figured a widget side workaround. related to this bug Importing custom css #39
  2. Passing custom messages back and forth to the kernel. Is custom message passing possible? #70
  3. This bug. building esm at python packaging time #71 - the least important of the core changes I'd like