feat: squad other section

[rebelchris]

Changes

NOTE:

WIP: lots of TODO's and TS errors, but love to hear your overall thoughts.

Idea:

• lean feed is less dependant on props and can work independant
• lean actions should eventually be used by everything so there is one sole hook for actions per post (it needs a good cleanup/split maybe even)
• modals should work via lazyModal and able to sit on top (still todo)

Events

Did you introduce any new tracking events?
Don't forget to update the Analytics Taxonomy sheet

Log the new/changed events below:

Type	event_name	value
Change/New	event name	extra: { ... }

Please make sure existing components are not breaking/affected by this PR

Manual Testing

On those affected packages:

• Have you done sanity checks in the webapp?
• Have you done sanity checks in the extension?
• Does this not break anything in companion?

Did you test the modified components media queries?

• MobileL (420px)
• Tablet (656px)
• Laptop (1020px)

Did you test on actual mobile devices?

• iOS (Chrome and Safari)
• Android

WT-{number} #done

[rebelchris]

The final idea is to have one cache for post states, regardless of who needs it.
As the "intermediate" solution I thought we could have this mapping per query to say what transformer to run on the provided cache. (one issue still is how to update multiple places)

[idoshamun]

I suggest looking for normalized cache solutions or ignoring it, and in any way I wouldn't recommend doing it in the same PR. Developing one ourselves is too much effort and bug-prone

[rebelchris]

Items here can actually be removed, but had to leave it for legacy stuff for now.

[rebelchris]

We either can overwrite or keep the default click action.

[idoshamun]

If this is to be a generic component, I suggest accepting classes from the outside and set it with default value

[rebelchris]

Good point indeed, most likely will take default "feed settings" and can get overwritten from outside.

[capJavert]

Great work on the POC, appreciate the effort 🚀

Excited to plan and move it forward.

[capJavert]

It could accept children as a function. So we can call:

Render cards:

<LeanFeed>
    {({ items }) => {
        return items.map((item, i) => {
            return <LeanFeedItemComponent key={i} item={item} />;
        }) 
    }}
</LeanFeed>

Add ad to the first place:

<LeanFeed>
    {({ items }) => {
        return items.map((item, i) => {
            if (i === 0) {
                return (
                    <>
                        <Ad />
                        <LeanFeedItemComponent key={i} item={item} />;
                    </>
                )
            }
    
            return <LeanFeedItemComponent key={i} item={item} />;
        }) 
    }}
</LeanFeed>

Of course internal render prop function is in fact just a component:

const FeedWithAds =  {({ items }) => {
    return items.map((item, i) => {
        return <LeanFeedItemComponent key={i} item={item} />;
    }) 
}}

<LeanFeed>
    {FeedWithAds}
</LeanFeed>

I think conceptually it would allow us to split view and business logic.

[capJavert]

Why cancel queries?

[rebelchris]

Won't be needed, was more a copy-paste from the existing function :)

[capJavert]

Why do we need this top level, it should be called just in nested components?

[rebelchris]

This can actually move into the nested components indeed.
The only exposure here I think was in case you can't to overwrite handlers?

Not sure if it's needed for that.

[capJavert]

I like the idea but I think component would need to be:

• split up into smaller parts/hooks
• based on your comment here it should support upvoting from single post as well
• we should also see if it can utilize mutation subscriptions to sync state between different caches (as current hooks do)
• should it solve props drilling in cards? feels like it should
• don't get me wrong it looks great just with current functionality I think it's lacking any benefits vs current set of hooks 🙏 🚀

[rebelchris]

Yeah 100% inline with the idea, Indeed the mutation subscription could potentially just check all caches for that postId and do something with it :)

And fully agree it should be split up again in singular logic, this was easier from a start point only.

[capJavert]

We need to be careful, this currently is going to make feed rendering as slow as it is now or worse.

Basically it should function the same as LeanOptionsButton where hooks down the render tree call useLeanPostActions and context only provides bare minimum like items and queryKey.

[rebelchris]

How would we go about overwrites for onClick for instance in that case?
These overwrites per feed are pretty much the only scenario for it now.

Would love to hear your thoughts on this.

[capJavert]

You do the custom logic in that specialized component?

[rebelchris]

But let's say it's canPinPost the page itself defines this.
The specialized component would have no way of knowing about it, unless it's contexted/prop drilled correct? (as it's implementation sits quite deep)

[capJavert]

canPinPost would be something that is in the context then yes and component can decide what to do with it.

[capJavert]

Technically, if we give single post query key it should invalidate single post cache?

[rebelchris]

Yep!

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
daily-webapp	❌ Failed (Inspect)			Mar 21, 2024 1:44pm

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
storybook	⬜️ Ignored (Inspect)	Visit Preview		Mar 21, 2024 1:44pm