-1
\$\begingroup\$

Below is my draft:

I have a working code to have 2 search bars with dropdown suggestions, selectable by both mouse and arrow keys in TypeScript and Fresh/Preact. In there I have to explicitly declare individual hooks and containers for different lists.

Pieces of working code

In an attempt to modularize it, I attempt to set hooks for the hooks:

Pieces of hooks of hooks

It doesn't work. Why is it the case?

My next step for this is to have the suggested lists disappear when they are unfocused by integrating it with Detect click outside multiple components

The draft is about what I've learned, tried, intended, struggled and questioned about, and it's more about helping myself think better and clearer. I don't intended to write it to any specific site. From my feeling SO will accept it – but that's a trivial fact – and CR won't like the why the try doesn't work – but I don't have any exposure to the site to confirm that. That's why I ask this question.

Bending the question to follow the site better is fine for me. It's just that I think if adding the attempt is fine, then when it doesn't work it's natural for the readers to be curious on why. So having a side, off-topic question on why it doesn't work in a main, on-topic one is acceptable, as I think answers including it enhance the learning better.

Should I just ask how to improve the working code without mentioning my try? It can be asked in SO. Or is it fine to include to the post?

\$\endgroup\$
1

2 Answers 2

3
\$\begingroup\$

Getting the original reviewed is on-topic. Asking why your attempt to refactor it is asking us to fix it and thus not on-topic. But you can absolutely include it as a 'this is what I've been thinking of', if you're not completely set of having that approach included in the end result. The suggestion can be freely ignored by reviewers, that's up to them

Practical example: I wrote this many years ago.

Relevant snippet:

I'm looking for a more idiomatic way to solve this. I think it can be done in a one-liner, something like:

return arr.sort((function(a, b) { return a - b; })).reduce(function(a, b) { /* */ });

But I'm pretty sure I'm heading the wrong way with the above.

What you suggest in your draft is not the same (and would likely not be well received), so you'll have to decide for yourself whether this is an acceptable deviation or not.

Keep in mind that for the question to be on-topic at all, you must act as maintainer of the code. Asking us to review a snippet you copied straight from someone on SO would not do. If you have adapted the code to your specific use-case and that works for you, we can review that. SO deals with example code, we deal with the actual code. Please see our guide for more differences.

So having a side, off-topic question on why it doesn't work in a main, on-topic one is acceptable, as I think answers including it enhance the learning better.

No. It is not. You can suggest it as a way of thinking to help the reviewers see what you have in mind. As additional context. You can not ask why something doesn't work. If you want to know about the why of something that does not work, there are other platforms available. Possibly Stack Overflow. On Code Review, you can ask about code that does work. And if you show something you've tried that looked promising but didn't work as a bit of additional context, there's no harm in that. However, that does not mean fixing your proposed implementation is in any way within scope.

\$\endgroup\$
10
  • \$\begingroup\$ yes, bending the question to follow the site better is fine for me. It's just that I think if adding the attempt is fine, then when it doesn't work it's natural for the readers to be curious on why. So having a side, off-topic question on why it doesn't work in a main, on-topic one is acceptable, as I think answers including it enhance the learning better. What do you think about this? Also, why do you see it's likely not well received? \$\endgroup\$
    – Ooker
    Mar 27 at 17:48
  • 1
    \$\begingroup\$ I think you misunderstood what I said. If necessary I can try to clear this up, but that will be in 20 hours or so. \$\endgroup\$
    – Mast Mod
    Mar 27 at 20:07
  • \$\begingroup\$ @Ooker Is the situation clear now? \$\endgroup\$
    – Mast Mod
    Mar 28 at 20:02
  • \$\begingroup\$ Yeah, it's clear that asking a side, off-topic question on why it doesn't work in a main, on-topic one is still a no for this site. I'll follow it. Still, if you can explain whether having all questions may come up in the same context be answered in one united place enhances the learning better or not will be great. I know that splitting them in multiple links will help focus on each question more, but why does the site prioritize that over the learning process and cannot tolerate the rule? Especially when the off-topic question is just a side one of a bigger on-topic \$\endgroup\$
    – Ooker
    Mar 28 at 20:41
  • 3
    \$\begingroup\$ @Ooker The way SE work is at first all questions are allowed. Over time the site notices certain questions lead to less than great results and bans such questions. Such questions don't have to 100% of the time lead to a bad result, so we accept some good questions are culled too. "Especially when the off-topic question is just a side one of a bigger on-topic" because unfortunately some people "[bend] the question to follow the site better" which causes the issues with the question to increase, and causes even more people to dislike off-topic questions. \$\endgroup\$
    – Peilonrayz Mod
    Mar 29 at 10:39
  • \$\begingroup\$ @Peilonrayz if you don't mind I'm interested with how the miscommunication happens. "In an attempt to modulize it, so that I can add more lists in the future easily, I attempt to set hooks for the hooks." I thought that including what I've been thinking of is fine. The broken code is equivalent Matt's snippet. I can see that saying "It doesn't work" may lead to an interpretation that I'm suggesting people to help me fix it, but my intend is just to add it's not yet a success refactor. \$\endgroup\$
    – Ooker
    Mar 29 at 13:13
  • \$\begingroup\$ "The reason why it doesn't work will be investigated in a SO question" – I thought this will emphasize that I don't want to ask how to fix it here. "In here, I wonder if this is a good approach or not" – I can see this can be read as I'm set on what the end result here. Perhaps writing it as "I wonder if this is an optimized way to add more lists in the future easily" \$\endgroup\$
    – Ooker
    Mar 29 at 13:18
  • \$\begingroup\$ @Ooker "In an attempt to modulize it, I attempt to set hooks for the hooks:" <code block> "It doesn't work. The reason why it doesn't work will be investigated in a SO question. In here, I wonder if this is a good approach or not." Looks like you are explicitly asking for feedback on broken code. If we look at the following sentence "My next step for this is to have the suggested lists disappear when they are unfocused by integrating it with Detect click outside multiple components." you have in no way indicated you want us to implement the code so doesn't fall under CNI. One is fine, one not \$\endgroup\$
    – Peilonrayz Mod
    Mar 29 at 13:26
  • \$\begingroup\$ @Peilonrayz why does this sentence "The reason why it doesn't work will be investigated in a SO question" still give the impression that I'm asking for feedback for it? What is CNI? \$\endgroup\$
    – Ooker
    Mar 29 at 13:30
  • 1
    \$\begingroup\$ @Ooker I didn't point to the sentence you have quoted alone. "In here, I wonder if this is a good approach or not." is asking for feedback about broken code. CNI stands for Code Not Implemented. You can see you have talked about code which hasn't been implemented with no issue because you haven't asked for feedback on the unimplemented code. \$\endgroup\$
    – Peilonrayz Mod
    Mar 29 at 13:32
1
\$\begingroup\$

We can't review the code that doesn't work. But it may be helpful to include something like that as an illustration of why you're not using that approach. That may avoid reviewers suggesting the exact thing you tried.

I recommend you use blockquote markdown to make it clear that this code isn't to be reviewed:

> ```
> /* the approach that sounds reasonable
>  * but doesn't produce the same result.
>  */
> ```

or

>     /* the approach that sounds reasonable
>      * but doesn't produce the same result.
>      */

However,

having a side, off-topic question on why it doesn't work

No, that's not permissible. If you don't know why some code doesn't work, Code Review is not the place to ask. Stack Overflow may be able to help, and if so, it's worth distilling a minimal reproducible example for that site and then incorporating what you learn into the code before asking for review here (not the other way around, because that is more likely to waste reviewers' time on code you eventually discard).

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .