Equivalent of Immutable.js directly in crate Yew

[cecton]

TL;DR

I'm currently developing an experiment of porting an equivalent of Imutable.js to Yew here: https://github.com/rustminded/yew-immutable/tree/main/examples

The question is: should this be part of Yew's core or an external crate?

Personal background

I've been using Yew for some time from 2 different perspectives:

1. As a user who develop a web app: I can't share anything as this is proprietary code unfortunately
2. As a library maintainer who wants to provide a port of Blueprint.js to Yew https://yewprint.rm.rs

Why immutability

In a react-like framework, props are passed down to components. Any mutation is done by the parent passing a different prop but you should never mutates your own props.

Why the hidden Rc

In a react-like framework, props are passed down from a parent to a children. When changes in props occur at the parent level, the parent propagate it to its direct children. Because it is the parent that is updated first, we can't provide references of the props to the children. That is why, when using Yew, we need to clone things a lot. We also wrap things in Rc a lot.

I don't think there is a way around this because that's the core design of the react-like framework. Thus I believe we should actually embrace it and add the tools to the user to be able to manage the props easily without having to write Rc everywhere.

Problems solved with this approach

In Yewprint we do have a lot of props in our components and we would prefer the clones to be cheap. In 0.18 we should have used Cow<'static, str> everywhere instead of String but it was deeply inconvenient. In 0.19 there is a lot more flexibility thanks to AttrValue and ImplicitClone developed by @hamza1311. Unfortunately there is still nothing to replace Vec and HashMap.

I think we can do the extra miles here and create the immutable+rc types for arrays and maps.

Why not other types

String, numbers, arrays and map are kinda primitives when developing a web app. Any other type will still need to be wrapped in an Rc in order to benefit from theses types. This is because I want to guarantee at compile time to the user that the cloning will be cheap.

Primitive types for numbers don't need to have an Rc so those will not be included in this change. But they need to implement ImplicitClone in order for this to work.

String needs to be place in an Rc. AttrValue is already doing a perfect job at that except for the Owned(String) variant. This is because this one could be uncheap but there is now way to know at compile time.

Arrays and Map need their own immutable type too so they can implement ImplicitClone and enforce their inner types to implement it as well.

Copy vs ImplicitClone

They are actually very alike. The only reason to not use Copy is because you can't implement it arbitrarily.

API

It would probably be beneficial to have an API that reflects JS and Immutable.JS. These are familiar and convenient for JS developers.

WTF THIS IS THE OPPOSITE OF RUST?!

This is. Yes. The first step that put us in this spot is because we are Yew: we imitate JSX and react components. Those are made with a dynamic language in mind and more particularly: with a garbage collector.

Nevertheless, the user will still be able to use their own types everywhere and optimize wherever they can.

Related to #2447

[voidpumpkin]

Should this be part of Yew's core or an external crate?

I think yew should position itself just to be a view library. (Just like react does) So i don't think this should be even part of the yew crate, but I guess you don't mean that here.

Then also I think it should stay external if you are the maintainer and us other maintainers don't show too much interest in maintaining this part of yew core.

So would I want to maintain yew immutable js / rs w/e? No, even now if I could I would never even look at yew-agents crate Pr's because I plain old don't get why even they are needed. So same case here, I don't think I would use immutable thing myself thus I would find it hard to maintain it.

Why the hidden Rc

Though i agree that any solutions like your proposed one here are great and the more the merier.
I would not want to block somebody from making a better immutable yew lib just because "yew already has native immutable js". (I know its not a real bloker, just a social/mental kind a blocker)

Maybe one day we will see that indeed super big majority of users use this and it a logical step to incorporate it into yew.

[cecton]

I plain old don't get why even they are needed. So same case here, I don't think I would use immutable thing myself thus I would find it hard to maintain it.

I actually wonder how people manage to achieve building components with the clone constraint. How do you declare your components props at the moments for types like:

• Strings
• Arrays
• Maps

Can you show me some projects you have?

[voidpumpkin]

Sadly all I do is for work and it's also not public.
But nothing to show, we clone things a lot, just we don't have any cases where that performance issue becomes visible for the user.

[voidpumpkin]

And mostly if I want to avoid cloning with Props drilling too mutch I just make a context. (use_context)

Or if I have too mutch clonjng when setting data then I switch from use_state to use_reducer.

[cecton]

That sounds like functional component with react hooks kind of things

[ranile]

The question is: should this be part of Yew's core or an external crate?

This shouldn't be related to Yew at all. What's stopping us from providing these data structures in a Yew-independent way? Let all Rust users benefit from them.

I don't think there is a way around this because that's the core design of the react-like framework. Thus I believe we should actually embrace it and add the tools to the user to be able to manage the props easily without having to write Rc everywhere.

I don't think fully embracing it is the best idea. This causes #1656 which is pain to deal with and ergonomic nightmare. Without language-level support, we can only do so much.

They are actually very alike. The only reason to not use Copy is because you can't implement it arbitrarily.

I had an idea of unsafe Copy types where you're on your own. From the outside, the type is cheap to clone. Internally Rc is practically just made of Copy types - Cell<usize> and raw pointers (or more accurately, NotNull<_>). This is unrelated here but compiler semantics to allow types like UseStateHandle, etc to be Copy would be nice to have.

[ranile]

One of the problem is the actual usefulness of this crate. I called it yew-immutable because it's only useful when building apps with Yew. It's kinda of an anti pattern for Rust development in general to put hidden garbage collection everywhere.

I think it might be better to not Rc the internal fields then.

let array = Rc::new(IArray::new()).
let array = array.iter().chain(std::iter::once(IString::from(name))).collect(); // rc here again if needed
// we can provide helper methods too
let array = array.into_rc();
let array = array.into_arc();

would be valid since everything works with &self

2. The most important part here is that the types implement ImplicitClone. That one is more complicated so let me break this down:

   1. ImplicitClone, as its name says, means the cloning can be implicit. This is the equivalent of the trait Copy in Rust. It is still useful to define ImplicitClone over Copy because Copy cannot be implemented on clone types. Therefore the name stands for "let this be cloned implicitly, it's cheap enough".

   2. ImplicitClone in Yew has another meaning: it's used by the html! macro to allow passing props without having to clone them first. See how in th is example I pass a reference of the object but Yew will actually clone it (exactly the same for AttrValue btw).

How about this:

pub trait CheapClone: Clone {}

#[cfg(feature = "yew")]
impl<T> CheapClone for T
    where T: ImplictClone
{}

You provide your own trait, that is implemented for yew behind a feature flag. No need to worry about moving ImplicitClone anywhere.

hmm you're right thinking I guess that's a +1 for moving AttrValue and ImplicitClone to their own separate crate so Yew can get rid of them in the future if we find a way?

Do you know of a way to possibly fix #1656? I don't

That sounds interesting. Probably best to give me a link to a doc or a repo or a discussion for it as it sounds it will digress from the subject here

Unfortunately, I never got to starting any real discussion on it. If you want to make a thread on internals forum or an RFC, feel free to.

[cecton]

I think it might be better to not Rc the internal fields then.

No the whole point is to have this Rc. Otherwise you can't share it to the children props 😖

You provide your own trait, that is implemented for yew behind a feature flag. No need to worry about moving ImplicitClone anywhere.

I tried already having my own trait but that didn't work at all. I think it was conflicting with other impls.

Do you know of a way to possibly fix #1656? I don't

No and I'm not sure if it is possible. The components are updated from root to children and grand children.

Unfortunately, I never got to starting any real discussion on it. If you want to make a thread on internals forum or an RFC, feel free to.

No I was hoping you would provide more details actually. I'm not sure what you had in mind that's why I'm asking...

[ranile]

I think it might be better to not Rc the internal fields then.

No the whole point is to have this Rc. Otherwise you can't share it to the children props confounded

Oh well... I guess you can just document it and say that it's an anti pattern and should be used when needed, while providing an example of when it's needed.

You provide your own trait, that is implemented for yew behind a feature flag. No need to worry about moving ImplicitClone anywhere.

I tried already having my own trait but that didn't work at all. I think it was conflicting with other impls.

That's something we can look into. I think it might be yet another case of we-need-specialization though

[cecton]

That's something we can look into. I think it might be yet another case of we-need-specialization though

Yes I think so too... though if #2447 gets merged I won't need to create my own trait at all.

Oh well... I guess you can just document it and say that it's an anti pattern and should be used when needed, while providing an example of when it's needed.

Yes though with the react component pattern it is needed everywhere. Every types you use in props need to be clonable and preferably cheap to clone. AttrValue is really what I meant to do but I didn't know you made it already. It definitely is that rc'ed cheap prop you can clone everywhere. IArray and IMap are just cheap clonable vecs and hashmap.

If the PR gets merged I can make yew-immutable. If it doesn't, then I'll be stuck. But tbh I like the idea you brought about having a more "general use" immutable crate. It's probably useful for other frameworks that use this react component pattern. Though I don't mind if you don't want this.

[ranile]

Yes I think so too... though if #2447 gets merged I won't need to create my own trait at all.

Merged it.

I don't like the idea of locking it to yew if it doesn't have to be. I've been trying to make code yew-independent. See things like gloo-worker, moving of services to gloo, removal of format module, etc