Notebook does not update reliably

[kalmdown]

Describe the bug After a refresh I have to manually force cells to calculate to get the result I expect.

Upon a refresh the cell that renders the vis has the following error: RuntimeError: Cannot read properties of null (reading 'getBoundingClientRect')

Forcing renderNodes to refresh fixes problem.

To Reproduce 1) Load https://observablehq.com/d/b17d4da7bdab0cb6 Is now in Issue state...to get to expected... 2) Force (shift-return) restructureData to calculate. 3) Force (shift-return) renderNodes to calculate.

Expected behavior Vis would be fully rendered after a refresh.

Screenshots On Refresh:

On hard refresh:

On forcing RenderNodes to calcuate:

Desktop (please complete the following information):

• OS: MacOS 11.6
• Browser Chrome 94.0.4606.81

Additional context Add any other context about the problem here.

[duaneatat]

Thanks for the bug report, taking a look now!

[mbostock]

This notebook employs antipatterns in Observable such as selecting from the global DOM.

d3.select('.'+iRolLoc)

Since these operations depend on mutable global state, the code will not work reliably. The code should be restructured to avoid mutating values defined in other cells and selecting from the global DOM.

[kalmdown]

Would good if, when user does that (especially new users like me) it could tell them about this. Otherwise there is no way users would know to look for this as a problem. - K

---

Karl Mochel Interaction, Interface, Information, Experience Design linkedin.com/in/kalmdown https://www.linkedin.com/in/kalmdown?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base_contact_details%3BpyZvd%2BHjSLSo3xELyIygSw%3D%3D

On Fri, Oct 15, 2021 at 8:02 AM Mike Bostock @.***> wrote:

This notebook employs antipatterns @.***/observable-anti-patterns-and-code-smells> in Observable such as selecting from the global DOM.

d3.select('.'+iRolLoc)

Since these operations depend on mutable global state, the code will not work reliably. The code should be restructured to avoid mutating values defined in other cells and selecting from the global DOM.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/observablehq/feedback/issues/267#issuecomment-944373225, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARECHUAU3HP4PFUXBRHGG3UHA7BNANCNFSM5GA7VQFA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[mbostock]

Would good if, when user does that (especially new users like me) it could tell them about this. Otherwise there is no way users would know to look for this as a problem. - K

Totally. Unfortunately, I don’t really know how to identify these patterns automatically—or at least, it’s hard to do it in general since there are lots of ways to mutate state—and provide commensurate guidance. Our strategy has been more in proactively recommending good patterns than trying to detect and correct antipatterns.

[kalmdown]

While it may be difficult for Ob to ID them, it's commensurately more difficult for beginners to know they are creating them. JS, Ob, DS etc are already a lot of subjects to learn. The expectation that a user learning a tool will read a document about anti-patterns above learning those is unrealistic. Having to also try to learn what not to do is a huge lift because it requires an architectural understanding of many subjects. D3 and Observable are great tools in concept but it's difficult to suggest them to other beginners with "hidden" issues that make execution sporadically or abstrusely problematic. As much as making creating easier and thus exciting and motivating, debugging and not making errors needs to be even easier because those are the things most likely to demotivate and turn off users. Some of the most important functionality that makes great tools is where expertise has been distilled into experiences that helps users not make errors.

---

Karl Mochel Interaction, Interface, Information, Experience Design linkedin.com/in/kalmdown https://www.linkedin.com/in/kalmdown?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base_contact_details%3BpyZvd%2BHjSLSo3xELyIygSw%3D%3D

On Fri, Oct 15, 2021 at 9:41 AM Mike Bostock @.***> wrote:

Would good if, when user does that (especially new users like me) it could tell them about this. Otherwise there is no way users would know to look for this as a problem. - K

Totally. Unfortunately, I don’t really know how to identify these patterns automatically—or at least, it’s hard to do it in general since there are lots of ways to mutate state—and provide commensurate guidance. Our strategy has been more in proactively recommending good patterns than trying to detect and correct antipatterns.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/observablehq/feedback/issues/267#issuecomment-944442976, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARECHVLCMMGJSR6YM4MAULUHBKTBANCNFSM5GA7VQFA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[mbostock]

I agree it’s a hugely important problem, and I like how you framed it. We’re working on it and care deeply about helping people succeed with Observable. I’m just saying there is no quick fix and I’m trying to set expectations around how and when we’ll be able to make progress on this issue.

[kalmdown]

Cool. Let me know if I can help. Be happy to participate in a workshop if you want to have one.

---

Karl Mochel Interaction, Interface, Information, Experience Design linkedin.com/in/kalmdown https://www.linkedin.com/in/kalmdown?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base_contact_details%3BpyZvd%2BHjSLSo3xELyIygSw%3D%3D

On Fri, Oct 15, 2021 at 10:27 AM Mike Bostock @.***> wrote:

I agree it’s a hugely important problem, and I like how you framed it. We’re working on it and care deeply about helping people succeed with Observable. I’m just saying there is no quick fix and I’m trying to set expectations around how and when we’ll be able to make progress on this issue.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/observablehq/feedback/issues/267#issuecomment-944472041, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARECHW7GLKGNKYDJG5IYO3UHBP6PANCNFSM5GA7VQFA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[kalmdown]

Would a copy of my notebook at this point, before trying to resolve these issues help provide examples for analysis?

---

Karl Mochel Interaction, Interface, Information, Experience Design linkedin.com/in/kalmdown https://www.linkedin.com/in/kalmdown?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base_contact_details%3BpyZvd%2BHjSLSo3xELyIygSw%3D%3D

On Fri, Oct 15, 2021 at 10:29 AM Karl Mochel @.***> wrote:

Cool. Let me know if I can help. Be happy to participate in a workshop if you want to have one.

---

Karl Mochel Interaction, Interface, Information, Experience Design linkedin.com/in/kalmdown https://www.linkedin.com/in/kalmdown?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base_contact_details%3BpyZvd%2BHjSLSo3xELyIygSw%3D%3D

On Fri, Oct 15, 2021 at 10:27 AM Mike Bostock @.***> wrote:

I agree it’s a hugely important problem, and I like how you framed it. We’re working on it and care deeply about helping people succeed with Observable. I’m just saying there is no quick fix and I’m trying to set expectations around how and when we’ll be able to make progress on this issue.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/observablehq/feedback/issues/267#issuecomment-944472041, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARECHW7GLKGNKYDJG5IYO3UHBP6PANCNFSM5GA7VQFA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[CobusT]

I think we understand the reason in this example, so please go ahead and try to resolve the issues in the notebook. Thanks again for this very useful feedback.

[triptych]

This was one of the major stumbling blocks for me and almost demotivated me to the point of quitting using this site. However, I think the solution is going to be more than some static analysis of a user's behavior and "warn" them -- I think it's going to be a combination of great documentation, great examples that display the best practices, and forums where novices can have a chance to learn from more experienced developers. While it's super frustrating that you can "shoot yourself in the foot" many ways in Observable, I would not want to have a ton of guardrails preventing me from doing things because perhaps there is something I want to implement in that way and I accept the consequences.

I think it's important to look at how people develop for the web before Observable, point out the reasonings why things happen - like immutability, reactivity, etc. and explain why they are desirable to learn.

I personally butted my head quite a bit around Observable's idiosyncrasies, but I did learn and it's made me a better web developer. But it was hard to find answers when things broke, but I don't think that means more error popups and code bloat, I think it means there needs to be better Documentation, better examples, and use cases where folks can see how to build things in an Observable friendly way.

[kalmdown]

I think the team has to decide what their priorities are. If the idea is to attract beginners (like me) then I don't think that documentation, and examples and use cases are the solution. I disagree that people should develop for the web before Observable because Observable is a great platform to learn to program. A new user doesn't need an IDE, web-server, NPM or a litany of other obstacles to get started creating cool things. It is a great constrained environment that allows for teaching a lot of programming principles without the weight that other environments carry. Having to read about abstract concepts and how not to do them is a huge barrier to entry. Users do not need to learn about immutability, reactivity, etc. until projects reach a level where these become likely. Only then is there a need or desire to learn how to deal with them.

I read the anti-patterns article, and while well written and mildly humorous, it does not help with the bigger problem - figuring out where I am doing the wrong thing. If keeping learners motivated on the platform is a priority, some kind of warning notifications that something might be problematic has a lot of value. Especially for these kinds of abstract issues that are hard to track down and understand.

An experience doesn't have to stop users from taking a direction. Like Grammarly, Observable can have a panel of icons (off the right rail of icons...) showing the number of instances of different issues, and the ability to Ignore if desired, not stopping you but offering another direction might be more suitable and why. That can go a long way towards helping users wrap their head around the issues and speed up their ability to produce. They will be especially motivated to solve the problem because it will be in their project, not some tutorial that they either cannot relate to or don't have the time to get through. With Observable's help they can learn and produce.

So, as an example, I would have liked in my notebook an indicator in the code with a banner that said something like, "It looks like you may be addressing an mutable object. This may cause your notebook to be unreliable. Check out this article to see why that is a problem and for possible fixes."

---

Karl Mochel Interaction, Interface, Information, Experience Design linkedin.com/in/kalmdown https://www.linkedin.com/in/kalmdown?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base_contact_details%3BpyZvd%2BHjSLSo3xELyIygSw%3D%3D

On Tue, Oct 19, 2021 at 2:23 PM Andrew Wooldridge @.***> wrote:

This was one of the major stumbling blocks for me and almost demotivated me to the point of quitting using this site. However, I think the solution is going to be more than some static analysis of a user's behavior and "warn" them -- I think it's going to be a combination of great documentation, great examples that display the best practices, and forums where novices can have a chance to learn from more experienced developers. While it's super frustrating that you can "shoot yourself in the foot" many ways in Observable, I would not want to have a ton of guardrails preventing me from doing things because perhaps there is something I want to implement in that way and I accept the consequences.

I think it's important to look at how people develop for the web before Observable, point out the reasonings why things happen - like immutability, reactivity, etc. and explain why they are desirable to learn.

I personally butted my head quite a bit around Observable's idiosyncrasies, but I did learn and it's made me a better web developer. But it was hard to find answers when things broke, but I don't think that means more error popups and code bloat, I think it means there needs to be better Documentation, better examples, and use cases where folks can see how to build things in an Observable friendly way.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/observablehq/feedback/issues/267#issuecomment-947116709, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARECHSUJXR6QNF4QTVL5ELUHXOWPANCNFSM5GA7VQFA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[shadoof]

Although I have come to know Observable much better and I still love it, and although I (sort of) understand its D3, DataViz orientation, it gives excellent no-install, flexible access to the full web stack, better than other such, so far. Thus, I am not alone in wanting to have intuitive, reliable DOM reference, without this being referred to as an "anti-pattern", and then also the NEXT UI complicates things/brings them to the fore. This from an earlier forum remark: "I'd like to open this up again because, perhaps, the Tom MacWright notebook (Observable anti-patterns and code smalls) referenced above needs an update for the 'Next' UI? Some of us will want to be manipulating the DOM contained in HTML cells and these cannot be given names (at least I can't figure out how to give them names). Couldn't HTML (and/or MarkDown) cells be given evaluation precedence? optionally? so that DOM references can be made reliable in a more intuitive manner?"

[CobusT]

Update: All cell types can now be named, see https://observablehq.com/@observablehq/release-notes#cell-938