import from a page?

[Fil]

I miss the cosiness of import {someFunction} from "@a/notebook"; I wonder if it would be useful to transpile import {someFunction} from "anotherpage.md" to import from /_import/anotherpage.md.[hash].js?

[mbostock]

I expressly think we should not do this and instead encourage people to move importable code into modules.

[declann]

Hi!

I searched for this recently when I wanted to abstract away a reactive container for some inputs (individual inputs changing relevance according to some changing top-level values => I want to enter and exit them with a keyframe animation; actually quite inspired by this :)

I used a module import instead: import/call an update function passing it a dom element and the relevant top-level variables => it's triggered reactively but that's where reactivity provided by Framework stops; then my function maintains some state on the dom element and calculates/executes it's dom changes also.

It's okay - the animations work - and its especially portable (and my big problem is finding the right pattern to maintain it as it grows => back into JS pattern fatigue!).

In my exact case the change I was forced to do was probably a good one (once I get it organised).

But it seemed unfortunate that - unless I'm missing something - then at the point of wanting to abstract reactive code across pages then the only option is to rearchitect and rewrite it?

And maybe what I'm missing is that reactivity isn't something which we need to travel to all the edges (it doesn't) and inside the Markdown pages at the top-level is where it gets the best bang for the buck so to speak, and that is the place where it's really good to cover.

Last thing to note about my usecase: since I also wanted to re-use the code in different places in one page, I guess I was really bound to run into problems with reactivity on top-level variables.
So what I was really searching for is import - with that OJS supports: that seems like it abstracts reactivity in a powerful way but I don't have much experience with it to know for sure.

Anyways, I did what Mike wants to encourage and I think I landed on something that's reasonable and very good in the long run; I'm just pointing out some of my thoughts as I went through this recently.

And if I missed an obvious approach please say!
Meanwhile I'll be drumming up the courage to get myself past some of that pattern/decision fatigue! 😃

[borango]

Hi @declann ,

first I had the same impression like you, that reactivity suffers when I refactor code from "Observable Cloud" reactive cells into functions or classes inside ESModules. Then I found 2 complementing answers to this situation:

1. reactivity is a great prototyping tool for the phase when I am growing a page from an idea in a very agile (iterative) way with little planning and much creativity. Once the code becomes more mature, and I tweak it much less frequently, then I can use this state to derive the dependencies between cells and create more classic (non-reactive) code in the shape of classes or functions. Code blocks in the new modules tend to get longer (compared to Notebook cells) because I can pack all code together which can execute in a "linear" control flow.

2. I could preserve most reactive benefits by keeping the structure of Notebook Cells / fenced code blocks, extract all the cell's implementing code into a module, and keep the function call (including parameters) in the cell / code block. This pattern goes well together with passing promises (like 'visible') to functions.

[declann]

I'm thinking about this challenge again and I find this comment helpful, thanks for sharing @borango !