sveltejs / rfcs Goto Github PK

Hi,

Out of interest I read part of the Svelte RFC particulary about state management. There I read about objections of using TC39 observables as store.
In this issue I hope I can nuance those objections a bit.

They don't represent a single value changing over time, but rather a stream of distinct values.

The most basic mode of observables is that they simply are a placeholder of a function (not state) which is called when you subscribe it. This makes them cold by default, yes.
But you can simply make an instance of an observable that represents current state. new BehaviorSubject('current state') acts very much like the writable example.
You can also make cold observables hot and let them act like having state by using the shareReplay(1) operator.

Two different subscribers to the same Observable could receive different values (!) ...

Not when they are hot (based on subject)
Furthermore, this is up to the developer whether he wants it to act in this way. A dev using TC39 observables should know the difference between hot and cold observables.
Actually, Observable is just a contract, which can behave like how a dev wants it to behave. They can behave exactly like stores in this RFC.

Observables can 'complete', but declarative components (in Svelte and other frameworks) deliberately do not have a concept of time. The two things are incompatible

A completed observable simply doesn't emit new values. Svelte can ignore this concept. Also a dev can choose to never complete an observable.
Also I don't understand what you mean by 'do not have concept of time'? State is usually something that changes over time. Completing simply means it doesn't change any longer...

They have error-handling semantics that are very often redundant (what error could occur when observing the mouse position, for example?).

When observables are used to represent current state (behavior), errors are (usually) redundant yes. Svelte can ignore that like 'completed'.

When they're not redundant (e.g. in the case of data coming over the network), errors are perhaps best handled out-of-band, since the goal is to concisely represent the value in a component template

In that case, the observable is usually not used as a behavior in templates (directly), but more as an async task like promise that can return a stream of values.
The nice thing is that in that case they can be converted to a behavior later because they have the same contract.
Also because the different usages share the same contract, they share the same rich set of operators too.

As an example, the 'derived store' example could be rewritten using a single existing operator: combineLatest.
A redux store can be rewritten like this:
const store$ = action$.pipe(scan((state, action) => reduce(state, action))
Where action$ can be a merge() of different action emitters.

I like the idea that the different modes can be modelled the same, so code and ideas can be shared, and devs have to know less to be able to interact with more frameworks.

I am looking over sveltejs/svelte#4661 and coming from sveltejs/svelte#1550 (Theming) and see that CSSOM will not be treated the same way as DOM, if we can't just use standard notation like in the dom (ex: {var}) it does not really make things simpler. Here is simpler.

For those of you who want dynamic CSS. CSS rules/declaration updating when Svelte variables change.

I would not normally create a new issue, but this is so simple when compared to sveltejs/svelte#4661 that it becomes an issue.

The following snippet uses https://emotion.sh/ which the author (no affiliation) describes as "Emotion is a library designed for writing css styles with JavaScript. It provides powerful and predictable style composition in addition to a great developer experience with features such as source maps, labels, and testing utilities. Both string and object styles are supported."

I give example of both Object and Strings

<script>
  import { css } from 'emotion'

  let primary = 'salmon';

  $: boxStyleObject = {

    backgroundColor: primary,

    '&:hover': {
      backgroundColor: 'tomato',
    }
  }
  // $: boxClass = css(boxStyleObject); // use object

  $: boxStyleCSS = `
    background-color: ${primary};
     &:hover {
      background-color: tomato;
    }
  `;
  $: boxClass = css`${boxStyleCSS}`; // use string

</script>

<svelte:head>
  <title>𝗖𝗔𝗧𝗣𝗘𝗔: Component Designer</title>
</svelte:head>


<input type="color" bind:value={primary}>

<div class="container">
    <div class="row">
      <div class="col p-3">
        <div class="box p-3 {boxClass}">

          Example Box
          {boxClass}

        </div>
      </div>
    </div>
</div>

Please look over the emotion docs for more: https://emotion.sh/docs/introduction

As to the issue of Theming (sveltejs/svelte#1550), I have bootstrap scss loaded via https://github.com/kaisermann/svelte-preprocess altering Bootstrap's scss code automatically re-compiles via https://github.com/sass/sass Here is my rollup.config.js: https://github.com/fantasyui-com/catpea-com/blob/master/rollup.config.js

As my private opinion, overall there should be no difference between handling of variable in CSSOM and DOM. Adding variable interpolation on CSS level, will cause this problem: https://sass-lang.com/documentation/variables where pre-processor functions will see var(--hello), intead of the value which pre-processors need for functions like darken(). In sass darken(var(--hello)) does not work as value of var(--hello) is not available to pre-processing. It is a run time variable with it's own behaviour (see Heads up! in https://sass-lang.com/documentation/variables for a nicer explanation)

I can see that Svelte has beat Vue and React,
You have earned a place in the History of Evolution of Software.
Upgrade to {cury-variable} interpolation in <style/> section to keep leading the way.

You are all amazing,
Thank You,
and apologies if I posted this in the wrong place.

I was directed to post this to the RFCs, so I am reposting this from. sveltejs/svelte#4843

I am posting here to get thoughts or pros/cons about the various solutions

Feature request description.

I think Svelte is missing an important feature that other frameworks like Vue have. We need a way to easily apply CSS to a child component from the parent without having to use the verbose selector :global(childSelector) {} inside the CSS

We should be able to apply CSS via classes to child components from the parent element. This is a missing feature that should be in svelte.

Describe the solution you'd like

imagine <Link/> is a component that renders an <a> element and has some scripts for routing (eg: event.preventDefault()), and you would like to style that <a> element from the parent

Solution 1:

Add an attribute such as descendants or something to the <style> element to let svelte know that these styles should apply to child components too

<Link href="/about">About Us</Link>
<style descendants>
// notice the descendants attributes (similar to how Vue has scoped
a {
  color: red;
}
</style>

Solution 2:

Allow Child components to be given some sort of attribute that tells svelte to pass the scope to the child component, eg:

<Link:scoped/>
or
<Link scoped/>
<style>
a {
  color: red;
}
</style>

Solution 3:

Allow targeting of components within the parent CSS. eg:

<style>

Link {
  color: red;
}

// or
:component(Link) {
  color: red;
}

</style>

Solution 4:

Get svelte to inject the component's unique scope ID as a class, which would allow nesting in preprocessors

<style lang="stylus">

:scope() a {
   color: red;
}
// or
:scope() {
  a {
     color: red;
  }
}

</style>

Output::

.svelte-123 a {
  color: red;
}

Describe alternatives you've considered

I have considered taking the selector :global(childSelector){} but it is far too verbose, especially if you have something like a <Link> component for JavaScript routing, and it might be found in your nav, sidebar, content, headings, footer (with each instance styled differently)

Not to mention that this only works if you wrap the component in something (selector) otherwise it would apply the global everywhere, eg:

<div>
   <Link href="/about">About Us</Link>
</div>
<style>
	div :global(a) {
		color: red;
	}
</style>

I would like to do something like this:

<Link href="/about">About Us</Link>
<style descendants>
a {
 color: red;
}
</style>

How important is this feature to you?

This is such an important issue that has been raised a number of times and I am begging the svelte team to consider adding anything like this.

I am willing to contribute adding these features if supported

Additional context

This issue has been raised many times:

@nikku summed this up perfectly

• sveltejs/svelte#2870 (comment)

Related issues:

• sveltejs/svelte#901
• sveltejs/svelte#4661
• #13
• sveltejs/svelte#4281
• sveltejs/svelte#2888
• sveltejs/svelte#4443
• sveltejs/svelte#2762
• sveltejs/svelte#1450
• https://github.com/sveltejs/rfcs/blob/style-properties/text/0000-style-properties.md

Add any other context or screenshots about the feature request here.

Since Svelte v3 is on its way and questions the status quo in the UI framework world again, I just wanted to come up with an idea how to make the template more compatible with JS. Maybe it was already in discussion for v2 or v3, so please forgive me if that was answered.

<script>
  // v3 syntax (maybe)
  export const numbers = [1,2,3];
  export let canEdit = false;

  const promise = () => getSuperhero(heroId) // returns a Promise

  const showDetails = (enemy) => {
    // ...
  };
</script>

<template>
  await (promise) {
    <p>Waiting...</p>
  } then (hero) {
    <!-- You must use strings, because Javascript can go anywhere -->
    <p>`Hello ${hero.name}`</p>
    <div>"Enemies:"</div>
    <ul>
      hero.enemies.map(enemy => <li on:click={() => showDetails(enemy) }>${enemy.name}</li>)
    </ul>
    if (canEdit) {
      <a href=`/superhero/edit/${hero.id}`>"Edit"</a>
    }
  } catch (e) { 
    <p>"Superheroes are in trouble"</p>
  }
</template>

Pro:

• The biggest advantage I see is that you already know JS and you don't have to learn special framework syntax (maybe "await" 😉) for e.g. control flow (something you keep hearing from the React community).
• Compared to JSX it looks way better (IMO)

Cons:

• You have to learn the new syntax if you're used to the old one.
• Work (if possible) that @Rich-Harris must do to make this possible.
• Maybe not the syntax that everyone loves.

What do you think? Is this something that would be possible? What disadvantage/advantage do you see?