💡Idea for Remix.guide website

[cliffordfajardo]

Hi @edmundhung
Since starting my learning journey Remix 💿 , you're website has been very helpful in saving me time from having to search the entire web for article and quality remix examples

I had some feedback regarding the Remix.guide user interface as it perhaps relates to helping more people take advantage of remix.

One thing I wish it was easier to do with the current UI is do filtered searches by content type or "tags". For example, as a user it would be nice to be able to click some checkboxes to do searches by tags or only view content with certain tags.

- article
- github repository
- tailwind
- graphQL
- authentication
- MongoDB
- SQL
- ant-design
- expressjs
- fastify
...etc

Implementation ideas

Since all resources need to be submitted manually or need moderator approval, we can collect the relevant information up front and add tags. All this nice data can be maintained in a JSON file or generated at build time, so that the UI can display the list quickly

An example image of Remix.guide alongside CollectUI website

One thing I like about collect UI is that the left sidebar has a list of topics. This is useful if you are in an exploratory state of mind or you don't know what you're looking for

The design of collectUI doesn't matter too much, my intent is to only illustrate UI enchancements for searching information on the website.

What I like currently about Remix.guide 💙 💿

• I like the sidebar
• I like the left sidebar and main content panel design that you currently created
• I like the useful links at the bottom of the sidebar (Remix docs, Github link, Discord)

Remix.guide is the most comprehensive remix resource in my opinion - thank you for taking the time to create it!

Let me know if I can help in any way; would love to be part of this awesome project

[edmundhung]

Hi @cliffordfajardo, I am so sorry for not being able to reply until now. I was just too busy for things like new job, relocating etc 😅

Thanks so much for spending the time writing this and I am glad that you find it helpful! Indeed, I have already done a POC that allows me to create a custom list on the UI which could be listed out on the sidebar similar to your CollectUI example. There are a few things I am not sure yet:

1. What lists should be created.
2. Should I allows nested list
3. Should I allow same bookmarks on several lists

I will probably squeeze some time and try delivering this in the next 2 weeks.

[cliffordfajardo]

There are a few things I am not sure yet:

1. What lists should be created.
2. Should I allows nested list
3. Should I allow same bookmarks on several lists

1. When you say list are you referring to the concept similar to the image shown of collectUI above?
I just want to make sure I'm on the same mental page as you 😄

Ideas:
Each of submission item you might think of as a resource:

 // 🚧 I know you have a schema already (PageStore.ts), just thinking high-level concepts below:
//  https://github.com/edmundhung/remix-guide/blob/main/worker/store/PageStore.ts#L11


type Resource = {
  tags: string[];
  title: '';
  subtitle: string;
  description string[]
  url: string[];
  createdAt: date;
  submittedAt: date;
  // ...
}

const resource = {
  title: `remix-graphql`
  url: 'https://github.com/thomasheyenbrock/remix-graphql',
}

2. Should I allows nested list?
I think to keep things simple for now, we should consider avoiding nested lists?
Every submitted resource could be considered an independent thing, all items being on equal level, and the thing that connects it to other things would be the tags. When you introduce hierarchy, it can make things more complex IMO, my suggestion is to avoid hierarchy for now as it can be resisted later
What do you think?

3. Should I allow same bookmarks on several lists?
Can you talk more about how you envision the lists feature to work? Apologies for making you write it out, but I think it would be a good way to better understand the scenario.

I haven't taken a look at the persistent storage / database solution you are using. Is it NoSQL like data storer (key-value) or is it relational SQL structure (tables/rows).

I think that can largely influence the implementation details.
Would you be able to share some resource/docs urls on related the worker store folder you have in this repo?
I want to learn more about the concepts, how to get started etc. I'm new to the cloudflare ecosystem, but I'm eager to understand it

• https://github.com/edmundhung/remix-guide/tree/main/worker/store

---

@edmundhung - another UI for inspiration
https://www.ycombinator.com/library?categories=Co-Founders

Wow just noticed there was filtered searches in remix.guide web app - they were a bit hidden, had to click the search icon 🤔

[edmundhung]

As you might also find out from the search, it is already possible to do some basic query based on the metadata, e.g. searching for repository, packages or even repository that are built with certain packages. In the previous version of Remix Guide, all the search options are listed on the sidebar which is similar to the Ycombinator example, but the options grows quickly and took most of the space from the sidebar. I think the UX is also not optimal for mobile user, so I changed it to the current design.

For the list concept, here is a work in progress typings for the new data structure I am working on:

export interface Page {
	url: string;
	author?: string;
	category?: string;
	title?: string | null;
	description?: string | null;
	dependencies?: Record<string, string>;
	configs?: string[];
	image?: string | null;
	video?: string | null;
	isSafe?: boolean;
	viewCount?: number;
	bookmarkUsers?: string[];
	createdAt: string;
	updatedAt: string;
}

// Resource will be renamed to Bookmark
export interface Bookmark {
	bookmarkId: string;
	url: string;
        list: string[];
	createdAt: string;
	updatedAt: string;
}

export interface List {
	slug: string;
	name: string;
        description: string;
        bookmarks: string[];
}

Each list is basically a collection of bookmarks and a bookmark can be available on different lists at the same time (So you can call it a tag as well). A list should represent a certain topic. That's why I believe it is gonna be quite similar to your Collect UI example.

The difference between list and the metadata I mentioned before is that metadata is collected automatically by scrapping the Github & NPM registry, while list is a manual setup. For example, I might create a list for Websites built with Remix / Official etc.

Also, Remix Guide use Durable objects instead of traditional database for storing the data. So you might find it unclear how the data is managed. 😅