Thanks for your work!

Here is a comparison:

Just some small notes:

1. it would look cleaner without the lines (as before)
2. i don't like the formatting of the longDescription. was better before
3. on nixpkgs channel, install command is still NixOS, for example nix-env -iA nixos.ffmpeg (NixOS channel)
4. on nixpkgs channel Platforms is empty
5. for the channel selection i would like to have buttons or links (don't hide behind dropdown)

or

The Ubuntu package search for comparison:

Different header for Nix page:

Looks bad because i used code for bootstrap 4.

Thanks for the review!

1. Zebra-striping

To reduce chances of misunderstanding, I have re-imported the nixos-site.css file on my standalone deploy. This fixes the zebra-striping and some of the concerns. That was present only on the standalone deploy.

2. Long description

I have fixed the look for longDescription, good catch, I hadn't realised it wasn't a <pre> on the current site.

3. Install command

I would need to have the most likely name for the channel available in the channel data json file, and use it instead of heuristically try to guess it some other way.

This wouldn't be really hard to add, so let's assume that it can be added and will be.

4. Platforms being empty

Ah! 18.09 changes the structure of the fields for platforms, like 18.03 did for the maintainers object. I'll have to case it depending on the structure.

EDIT Oh my oh my, this may need some work on nixpkg's side. Here's what I get for platforms.unix:

[
  {
    "kernel": {
      "families": {
        "bsd": {
          "_type": "exec-format",
          "name": "bsd"
        }
      }
    }
  },
  {
    "kernel": {
      "families": {
        "darwin": {
          "_type": "exec-format",
          "name": "darwin"
        }
      }
    }
  },
  {
    "kernel": {
      "_type": "kernel",
      "execFormat": {
        "_type": "exec-format",
        "name": "elf"
      },
      "families": {},
      "name": "linux"
    }
  },
  {
    "kernel": {
      "_type": "kernel",
      "execFormat": {
        "_type": "exec-format",
        "name": "elf"
      },
      "families": {},
      "name": "solaris"
    }
  },
  {
    "kernel": {
      "_type": "kernel",
      "execFormat": {
        "_type": "exec-format",
        "name": "elf"
      },
      "families": {},
      "name": "hurd"
    }
  },
  {
    "abi": {
      "_type": "abi",
      "name": "cygnus"
    },
    "kernel": {
      "_type": "kernel",
      "execFormat": {
        "_type": "exec-format",
        "name": "pe"
      },
      "families": {},
      "name": "windows"
    }
  }
]

This is, uh, probably more verbose that what we want. We'll probably need some kind of "toString" that gives us something to print to the end-user.

5. Channel selection

Nothing is impossible, but the way I built it was to reduce the amount of information on-screen at once. Though it should be trivial to try out a different appearance (e.g. styled radio buttons; styled enough that the round button doesn't show up).

The goal is to make sure everything is accessible. E.g. the rows on the current listing aren't accessible using vimium (pressing F doesn't show a letter to access a row) or TAB-navigation. To smooth out the issue in the re-implementation I made sure to use an element that can be reached using keyboard-only navigation.

I'll (as the last thing to fix) look at alternatives to the select box.

When I'm opening https://nix.samueldr.com/explorer/, it loads quite slowly. Is this because your personal server is slower than nixos.org, or is your javascript somehow less efficient?

Small grammar fix:
"This package is unfree. See chapter 6.2 of the manual for more informations."

"informations" -> "information"

@turion sorry for the delay, had a busy week-end. What do you mean "it loads slowly", is it stuck on the loading animation (three dots growing and reducing)? In that case, that means it's downloading.

My server does serve the file much slower than the nixos.org server serves the file. (2.18s vs. 0.511s!). Though, comparing the time after the channel data is downloaded, it doesn't look like it is slower to run.

Also note that there is an extra download that must be first done (+96ms here), which will always add the time for one server round-trip. That download is the list of channels that are available. This allows managing the available channels outside of the explorer's code.

Thanks @ryantm for the remark!

This is also live on my demo page.

It looks like the old website would cache the .json file and yours is not? That could account for the performance differences.

Also, if you don't get much response on this, be sure to email the mailing list. I think this is in the right direction on fixing stuff. Some people might think it is too much new code to maintain and maybe it needs its own repo/external link.

Yes, it seems the slow-down is just because the file is served slowly. Great otherwise!

overall seems like a solid improvement - the current version is pretty barebones and also loads slow

Stack choice is familiar and I at least like it. in case you want to write some tests I like the Jest framework - jsdom gives you some great power to build non-fragile UI tests. also recommend prettier

long-term, not sure that loading the entire packages file is the best approach, especially when (1) there's pagination to show only 15 results and clicking on a separate distribution fetches another big file and (2) the file could grow far larger as time passes. ideally seems like you could efficiently filter the results and render the page on the server and then fetch the rest as needed when the client clicks thru pages. but I don't want to derail your work and not sure what the view around here is on a server

the slow load for me:

1200 kilobytes / 21 seconds = 57 kilobytes/s
seems like your server really doesn't like sending stuff to my client - but on refreshes seems like got to a more reasonable speed 😄

don't have a ton of capacity to help but feel free to hit me up publicly or privately if you want to chat frontend

The current demo makes a new history entry on every button press, which means I had to go "back" in the browser like 20 times to actually get to the last website after playing around for a bit.

I don't know much about javascript, but I think such instant-transition-inducing button presses shouldn't cause new history entries. In the users (my) eyes, it is still the same webpage, so it shuoldn't do that. I occasionally happen to find other websites online that do this, but was never fond of that.

^{(Related IRC log for the record)}

Yeah, though your argument is artificially limited to something you feel.

Let's dwell only on the pager previous/next page for now.

Technically speaking, when you click on the "next" button on the issues page, do you expect it to push an navigation event to your history or not? You probably do. Well, the load, while not entirely instantaneous, isn't a full page load; JavaScript did things and only made partial changes to the page.

In this re-implementation of the searcher, clicking on the "next" button, you wouldn't expect to have a navigation event pushed on the stack. In this particular case, the load is a bit more instantaneous, but the same mechanism are in use; JavaScript does things and makes a partial change to the page.

AFAICT (and I'm not trying to be contrarian here!) the only difference in the pager is that one is wicked fast while the other is slower. The github page load is slower since it fetches the data in the background (still via JavaScript). The package searcher is faster since all of the data is pre-loaded due to how we lazily load all the data upfront.

Here's a hill I'm prepared to get bruised on: the behaviour of a webpage shouldn't change because of the way the back-end has been architected. Following a link should add a navigation event to the history, and change the URL accordingly; the changed URL should load the site to work the same way if accessed directly.

Now: here's to the one issue I concede is a hard one to solve right:

When should a navigation event be made on the history stack for a live-changing result.

The best solution I found from experience is to pop on blur¹ (and on occasion, blur on enter press). It feels fine to me to expect that on blur, the user has "committed" the changes and is ready to peruse the results.

Not touching the history in that case will cause weird issues considering other actions touch the history. You would move back and forth into the history and be missing the first page of the results, it would be:

• foo 2
• foo 3
• foo 4
• bar 2
• bar 3

Instead of:

• foo 1
• foo 2
• foo 3
• foo 4
• bar 1
• bar 2
• bar 3

The "dumb" solution to this problem is to reduce the apparent functionality and force committing the change. Instead of live searching and updating the whole page, showing suggestions in another control/component, allowing completion, and then asking for an action (pressing enter, clicking a Search button) to commit the new search; thus pushing the new navigation event to "page 1 of new search".

1: blur, when the focus exits the field. Either by tab navigation, clicking elsewhere, etc.

@samueldr what's the status here?

I would love to have it! (especially archived packages.json for repology)

Still waiting for comments from those in charge of the site. I'm still unclear as to whether the feature is desired, whether the implementation is fine, what needs to be done to upstream this. I pretty much haven't touched it at all since not knowing could mean efforts go in the wrong way with regards to what's desired.

I'm willing to polish this up any way desired, even re-do parts of it if needed, but I need some direction to do this.

cc @edolstra @zimbatm as people in charge of this site (I'm not sure if there are others).

To add to the previous comment: I'm glad to work with you for any issues, perceived or real about this PR. After all, this adds a big chunk of machinery in the website build, and is probably not optimally done.

@edolstra @zimbatm would it be possible to move this forward? @samueldr is ready to continue work on this PR, but would need some direction as to what's OK and what's not in the current state of this PR, if I interpret the last comment correctly.

This is really good work and I would be happy to merge the PR as is (once the merge conflicts are fixed).

In the long term, I would like to see the NixOS options, nixpkgs packages.json and manuals be published by the channel release script instead and have the nixos.org website be essentially a static page that loads the JSON using CORS. It would be nice if that was also tackled here but I understand that it would expand the scope of the PR.

@samueldr can you resolve the merge conflict? 🚀

@samueldr what does the (NixOS Channel) mean next to the install command?

This comes from the existing packages page. I'm not entirely sure what it should mean. We may as well drop that.

If you feel like it. Things are already much better like that.

I also have my eyes on the maintainers field. It would be nice to get the github handle or a link to the maintainer meta attributes instead of just the name and email.

Improvements to build upon :)

(Yes, good ideas, and things that should be easier to implement in the end.)

When turning on unfree packages, I'm finding the contrast of an unfree package to be hard to read on odd zebra striped package details. The text is #666666, the background is F5F5F5. It does pass minimum contrast accessibility requirements, though, so I won't block on it.

About unfree software

The project's view about unfree software is known. We shouldn't promote unfree software.

This rewrite of the packages-explorer was written in a way that is easy to extend, and any part can easily be removed or tweaked as desired, including the filter for unfree software (which defaults to hide them). The cost of adding such a filter is much reduced compared to the previous codebase.

Still, my personal opinion is that it is a usability issue not to list unfree software in some way. Though, I do agree that we shouldn't promote unfree software, which is why they are gated under a toggle, and phrasing is added to every unfree software entry. The tone of that note was initially more neutral-to-negative by design.

Seeing that the foundation depends on unfree software, it seems weird to me to completely hide the presence of unfree software from the packages set, acting as if it didn't exist.

As a closing note, more details about my view. A part of Freedom, is the Freedom of choice, including the choice of using unfree software. We should better educate the user so they make an informed decision about their choice of using unfree software, and we can make it obvious what the position of the project is. Hiding the fact that the project has unfree software, while still packaging it is probably unwise, and does reduce usability for the users that have decided that the drawbacks of unfree software is worth it for their needs. Some users probably have skipped this distribution, thinking that they couldn't use some unfree software, possibly a hardware driver.

I have just now cut off the unfree part, part of #300 that is meant to apply on master once this is merged.