Components map a name to a group of sub-token properties: ... Variants (hover, active, pressed) are expressed as separate component entries with a related key name.
大多数人认为组件变体应该通过嵌套结构或条件逻辑来组织，这是现代UI框架的标准做法。但作者选择将每个变体表示为独立的组件条目，这种扁平化结构挑战了组件变体的传统组织方式，可能使某些复杂场景的维护变得更加困难。
Components map a name to a group of sub-token properties: ... Valid component properties: backgroundColor, textColor, typography, rounded, padding, size, height, width.
大多数人认为组件应该被定义为完整的、独立的实体，包含所有必要的样式和功能。但作者认为组件应该被定义为对已有设计 tokens 的引用和组合，而不是独立的样式定义。这种方法挑战了传统的组件设计理念，强调了设计系统中的复用性和一致性而非组件独立性。
When writing component tests that involve two-way bindings, context or snippet props, it’s best to create a wrapper component for your specific test and interact with that. @testing-library/svelte contains some examples.
This seems to be more than just a thin wrapper like https://github.com/rainerschuster/final-form-material-ui was. I kind of prefer the simplicity of focus of final-form-material-ui.
This appears to be attempting to do too much. Though if it gives you exactly what you want, great.
Noise
Noise is anything interfering with clear communication; distractions that occur during communication that resolves in misinterpretation.
Internal noise: psychological or physical problem someone is dealing with during communication
External noise : Environmental components that cause distraction
Semantic noise: a disturbance in the transmission of a message; interferes with interpretation of the message due to words having more than one meaning.
A connotation: positive or negative emotional connection to a definition. connotative semantic noise is more of an emotional issue with the intended use of words.
Denotation: the literal meaning of a word; denotative semantic noise: when we hear or see language we cannot define therefore we cannot interpret.
we should break down and MR into "Blocks"
The Mailer is not the right place for business logic. When you use Sidekiq than your Job object should do the check before actually calling the Mailer.
The Mailer, IMHO, is the wrong place for this logic. The mailer should do nothing but format and send messages. The logic to decide whether or not to send should be within the calling block of code.
condensing the information into two- or three-dimensional spaces. A very good overview of techniques to achieve this was written by Paliy and Shankar (2016).
2. No hierarchy
Defang the hierarchy! Flattening all the management levels and leadership.
1. Total transparency
All info all of the time available to all makes for a trusting space. Plus, a more active way to help all your people understand what they are seeing.
it is not part of Svelte but it is part of Svelte Preprocess github.com/sveltejs/svelte-preprocess#global-style
Note: Safari is not WebKit. Safari bugs should be reported to Apple.
There are project layouts that put implementation files and test files together.
This is an unofficial, complete Svelte port of the Headless UI component library (https://headlessui.dev/)
this happens with getClient and setClient because it is a svelte context which is only available at component initialization (construction) and cannot be in an event handler.
Components let you split the UI into independent, reusable pieces, and think about each piece in isolation.
I like this definition of 'components'.
Moutinho, S., WadmanApr. 30, M., 2021, & Pm, 5:40. (2021, April 30). Is Russia’s COVID-19 vaccine safe? Brazil’s veto of Sputnik V sparks lawsuit threat and confusion. Science | AAAS. https://www.sciencemag.org/news/2021/04/russias-covid-19-vaccine-safe-brazils-veto-sputnik-v-sparks-lawsuit-threat-and
Components are the core of MJML. A component is an abstraction of a more complex email-responsive HTML layout. It exposes attributes, enabling you to interact with the final component visual aspect.
There’s several benefits to splitting code into multiple packages, whether it be a library, micro-services or micro-frontends.
First of all, I would say it is not good to use margin on the component’s top-level, because it breaks the isolation of components.// A React component with margin set on top-levelconst MyComponent = () => { return <div style="margin: 1rem">...</div>;};margin here is not just affecting the component itself, but also affecting other components (e.g., it is pushing off another component / element sitting next to it)If we want to place this component in a different context or layout, margin would get in the way of resuse
当然ながら、コンポーネントのトップレベルでマージンを使うことは次の２つの理由から良くない。
Suppose that the validate task was getting quite complex and bloated. When writing “normal” Ruby, you’d break up one method into several. In Trailblazer, that’s when you introduce a new, smaller activity.
One of the main reasons to work with components is re-usability and portability, but also a delegation of responsibilities. Adding a component should be as easy as simply adding the component without having to know the inner workings (or markup) of this component. A consumer should only be aware of the properties, methods and events of a component. In order to style a child component one has to be aware of the markup as well, which violates this 'delegation of responsibility'-principle.
Trailblazer offers you a new, more intuitive file layout in applications.
Instead of grouping by technology, classes and views are structured by concept, and then by technology. A concept can relate to a model, or can be a completely abstract concern such as invoicing.
No one has requested it before so it's certainly not something we're planning to add.
To give a little more context, structures like this often come up in my work when dealing with NoSQL datastores, especially ones that rely heavily on JSON, like Firebase, where a records unique ID isn't part of the record itself, just a key that points to it. I think most Ruby/Rails projects tend towards use cases where these sort of datastores aren't appropriate/necessary, so it makes sense that this wouldn't come up as quickly as other structures.
The alternative is uncontrolled components, where form data is handled by the DOM itself.
In a controlled component, form data is handled by a React component.
Thanks to that I have chance and time to properly initialise all the properties without reactive calls and I do not have to ignore these "initialising" events before proper initialisation.
Knowing exactly what happens in your application can mean the difference between feeling in full control or experiencing deep frustration. Personally, unknowns drive me crazy, which in turn often leads to all sorts of experiments and/or debug sessions.
Theemergence of the termcontent strategyitselfrepresents widespread recognition that componentcontent management was in great need of aroadmap.
For me this is one of the key sentences of this paper. It is impossible to understand content strategy without taking component content management into consideration. For an academic approach to content strategy component content management is a key.
In its most commondefinition, a genre is a rhetorical action that istypified and socially recognized based on recurrentsituations; members of organizations use genresfor specific communicative and collaborativepurposes [6], [7]
This might be translated following the approach of semiotic practices defined by Fontanille et.al.
What is a data-originated component? It’s a kind of component that is primarily designed and built for either: displaying, entering, or customizing a given data content itself, rather than focusing on the form it takes. For example Drawer is a non data-originated component, although it may include some. Whereas Table, or Form, or even Feed are good examples of data-originated components.
Sometimes, systems just scale the problemA UI design system is more than the code of a component library. It’s more than the colors, styles, and margins of your elements. It’s an ever-growing and ever-evolving creature that entails your brand and your user’s feelings.
If you don't understand the problem - you can [[scale the problem instead of solve the problem]], and it's important to remember that a [[design system is more than a component library]]
For use$ since svelte is never going to support actions for components, i designed something that reminds React hooks that will in some ways replace this feature.
Isn't that what use$ is trying to do already? How is that "something that reminds React hooks" any different? Will be interested to see...
It's been a while since I had to write a typeahead without RxJS but this took some time and a lot of code. The implementation also contained fewer features, as the cancellability of previous requests. Sadly, most of the time, the implementation also introduced bugs. But with RxJS, this becomes trivial. By using some RxJS operators we end up with a working typeahead, without the bugs, which is thoroughly tested, and has more features. All of this, with less code.
Another difference is that context in Svelte does not insert anything into the visual component tree. There is no <Context.Provider> element like in React
class: '' - A CSS class string.
Doing a HOC properly, as a library should, with hoisted statics and displayName and ref, etc., is a hassle and would add unnecessary bulk.
// Make a HOC
// This is not the only way to accomplish auto-save, but it does let us:
// - Use built-in React lifecycle methods to listen for changes
// - Maintain state of when we are submitting
// - Render a message when submitting
// - Pass in debounce and save props nicely
export default props => (
<FormSpy {...props} subscription={{ values: true }} component={AutoSave} />
);
For the sake of best compatibility we convert the className attribute to class for svelte.
Svelte refuses to standardize on any way to pass a CSS class. I thought className was actually the most common name for this prop though even in Svelte...
There is a killer feature of vDOM that Svelte has nothing to replace with. It is the ability to treat component hierarchy as an object.
But it’s really hard to see, because our human brains struggle to think about this Clock function as something for generating discrete snapshots of a clock, instead of representing a persistent thing that changes over time.
(One can already destructure the loop variable but using a store obtained that way currently throws an error - Stores must be declared at the top level of the component (this may change in a future version of Svelte))
When using React hooks there is no concept of onMount because the idea of only running some code on mount leads to writing non-resilient components, components that do one thing when they mount, and then don’t take prop changes into account.
A component shouldn’t break because it’s rendered more or less often.
Keep the local state isolated.Think about which state is local to a particular UI representation — and don’t hoist that state higher than necessary.
Props and state can change, and components should handle those changes whenever they happen.
Even if a component is rendered just once, your design will improve if rendering twice doesn’t break it.
Recoil defines a directed graph orthogonal to but also intrinsic and attached to your React tree.
In general it is recommended you handle forms in this "controlled" manner. In some cases it might make sense to manage the form state outside of Solid via refs. These "uncontrolled" forms can also work. Just be conscious of the difference as mixing approaches can lead to unexpected results.
I took the same approach with _layout.svelte and not just for the svelte-apollo client. Except I put all of that setup into another module (setup.js) and imported from _layout. I just couldn't stomach having all that code actually in my _layout file. It's for layout, supposedly, but it's the only component that is a parent to the whole app.
setContext must be called synchronously during component initialization. That is, from the root of the <script> tag
It looks like the issue stems from having "svelte" as a dependency instead of a devDependencies in package.json within the sapper project. This causes import 'svelte' to load the rollup excluded npm package's set_current_component instead of from within the sapper generated server.js.
Most simple example: <script> import ChildComponent from './Child.svelte'; </script> <style> .class-to-add { background-color: tomato; } </style> <ChildComponent class="class-to-add" /> ...compiles to CSS without the class-to-add declaration, as svelte currently does not recognize the class name as being used. I'd expect class-to-add is bundled with all nested style declarations class-to-add is passed to ChildComponent as class-to-add svelte-HASH This looks like a bug / missing feature to me.
I wrote hundreds of Rect components and what I learned is that Componets should be able to be styled by developer who is using it.
color: red; //doesn't apply this rule, because scoping doesn't extend to children
Say I want to style this javascript routing anchor tag on various pages (some may be buttons, plain links, images) it makes it incredibly difficult. Eg:
Having to wrap everything in a selector :global(child) { } is hacky
I think instead, there would need to be some special way to make the distinction of what is a slot attribute and what is a slot prop to be consumed with let:. Maybe a new directive like <slot attr:class="abc"/>?
feel like there needs to be an easy way to style sub-components without their cooperation
Allow creating custom components with the same abilities as native dom. By all means keep the same level of encapsulation, don't push class on components, but allow a component to mark the class property or another as a CSS Class property, in which case you could pass it through the same transformation that native elements go through
The problem with working around the current limitations of Svelte style (:global, svelte:head, external styles or various wild card selectors) is that the API is uglier, bigger, harder to explain AND it loses one of the best features of Svelte IMO - contextual style encapsulation. I can understand that CSS classes are a bit uncontrollable, but this type of blocking will just push developers to work around it and create worse solutions.
There is a good amount of properties that should mostly be applied from a parent's point of view. We're talking stuff like grid-area in grid layouts, margin and flex in flex layouts. Even properties like position and and the top/right/left/bottom following it in some cases.
Svelte will not offer a generic way to support style customizing via contextual class overrides (as we'd do it in plain HTML). Instead we'll invent something new that is entirely different. If a child component is provided and does not anticipate some contextual usage scenario (style wise) you'd need to copy it or hack around that via :global hacks.
Explicit interfaces are preferable, even if it places greater demand on library authors to design both their components and their style interfaces with these things in mind.
The RFC is more appropriate because it does not allow a parent to abritrarily control anything below it, that responsibility still relies on the component itself. Just because people have been passing classes round and overriding child styles for years doesn't mean it is a good choice and isn't something we wnat to encourage.
This allows passing classes to child components with svelte-{hash} through the class prop and prevents removing such classes from css.
This has already forced me to forgo Svelte Material because I would like to add some actions to their components but I cannot and it does not make sense for them to cater to my specific use-case by baking random stuff into the library used by everyone.
The point of the feature is to not rely on the third-party author of the child component to add a prop for every action under the sun. Rather, they could just mark a recipient for actions on the component (assuming there is a viable target element), and then consumers of the library could extend the component using whatever actions they desire.
They don't need to add a prop for every action. The action itself can be passed in as a prop. <script> export let action; </script> <div use:action>whatever</div> The argument for the action can be another prop or can be part of the same prop.
Your LazyLoad image is now inextensible. What if you want to add a class? Perhaps the author of LazyLoad thought of that and sets className onto the <img>. But will the author consider everything? Perhaps if we get {...state} attributes.
Provides state management for tree-like components. Handles building a collection of items from props, item expanded state, and manages multiple selection state.
However, we've another unresolved problem - passing parent's styles to child components.
The primary motivation for this change is to have the same behavior between dom elements and wrapper components. Class directives are extremely convenient but that convenience is lost when a section of code needs to be converted to a component.
This is especially useful for components that are a simple wrapper around a dom element.
It’s become increasingly common to divide code into components, rather than by file type. React, for example, allows for the collocation of a components markup and JavaScript. In Svelte, this is taken one logical step further: the Javascript, markup and styling for a component can all exist together in a single `.svelte` file
With Svelte, components and files have a one-to-one relationship. Every file is a component, and files can't have more than one component. This is generally a "best practice" when using most component frameworks.
This is easily solved by extracting components, either as template partials/JavaScript components, or using Tailwind's @apply feature to create abstractions around common utility patterns.
If you can, use AMP like any other JavaScript library to build your site and forget about the canonical linking. Using AMP to build a whole website dramatically reduces your maintenance burden.
Autocomplete
Also notice that the component name Nested is capitalised. This convention has been adopted to allow us to differentiate between user-defined components and regular HTML tags.
Mohseni-Kabir, A., Pant, M., Towsley, D., Guha, S., & Swami, A. (2020). Percolation Thresholds for Robust Network Connectivity. ArXiv:2006.14496 [Cond-Mat, Physics:Physics]. http://arxiv.org/abs/2006.14496
We don't have an internationalization group. That responsibility is shared across many groups. We might instead have an internationalization tooling group.
We don't have a performance group. Ensuring GitLab is performant is the responsibility of all groups.
It is not the browser's responsibility to auto-login to websites. This is the responsibility of the website you are accessing. The browser can remember form data and auto-fill for you, as can various extensions like LastPass.
return <Lower
Interesting naming convention: Higher and Lower components.
ΛLIΛ
MINIMALISTIC
Not maintained actively enough. Check out https://github.com/insin/nwb#react-components-and-libraries or https://neutrinojs.org/packages/react-components/
Instead of overriding a service with your own implementation, you enhance an existing service with your own concerns. This pattern is known as middleware.
Injector components should never be self-closing, and they should never wrap multiple children. We can fix this at code-time and not wait for the errors at runtime.
child
React Native has also used this pattern in TouchableWithoutFeedback
we use a LOT of injector components to abstract out logic and nicely separate concerns like style, animation, and interactions from our layout components.
An injector component takes props, optionally computes new ones, then injects them into its child via React.cloneElement(). Crucially, it also does not add any new components to the DOM.
Null Components should never have children - they'd never be rendered.
Aligning closely with the <Injector_ > naming convention, Null Components are denoted with a prefix and postfix _ (e.g. <_NullComponent_ />).
The idea is that the additional prefix _ of a Null Component symbolizes that it adds even less to the DOM than an Injector. I picture the name falling through to become just the _, like the unused argument convention in javascript functions: const handleEvent = (_, id) => { console.log(id) } .
Not clear whether it could (easily) be used "standalone" — without any child checkboxes.
However, in this case you would lose the possibility to render something in between. You are strictly coupled to the higher-order component's render method. If you need to add something in between of the currency components, you would have to do it in the higher-order component. It would be quite similar as you have done it previously by rendering the currency components straight away in the Amount component. If using a render prop component instead, you would be flexible in your composition.
For the sake of completeness, the following code demonstrates that the problem could be solved with a higher-order component (HOC) as well:
Since an uncontrolled component keeps the source of truth in the DOM, it is sometimes easier to integrate React and non-React code when using uncontrolled components.
A good example for when to use uncontrolled components
The terms “controlled” and “uncontrolled” usually refer to form inputs, but they can also describe where any component’s data lives. Data passed in as props can be thought of as controlled (because the parent component controls that data). Data that exists only in internal state can be thought of as uncontrolled (because the parent can’t directly change it).
So the main thing this gives us is a way to set indeterminate property of input via an indeterminate property?
This is misnamed. Doesn't actually give us a tri-state checkbox. Just a binary checkbox.
input.indeterminate = indeterminate
So the main thing this gives us is a way to set indeterminate property of input via an indeterminate property?
Not sure how that supposedly gives us a tri-state checkbox.
Need demo to understand what it does. Find one among https://github.com/search?q=reactabular-sticky&type=Code ?
3. Deployment as Memory Management
The entire chapter 3 is worth reading. Great resource on what a package (or more broadly, a component) is in regards to Nix.
Specifically "3.1 What is a component?"
However, if more control is needed, you can pass any of these pieces of state as a prop (as indicated above) and that state becomes controlled. As soon as this.props[statePropKey] !== undefined, internally, downshift will determine its state based on your prop's value rather than its own internal state.
Popout
setState({isOpen: true}
We've extracted some key features into separate HOCs to keep the main library as small as possible
You can control the following props by providing values for them. If you don't, react-select will manage them for you. value / onChange - specify the current value of the control menuIsOpen / onMenuOpen / onMenuClose - control whether the menu is open inputValue / onInputChange - control the value of the search input (changing this will update the available options) If you don't provide these props, you can set the initial value of the state they control: defaultValue - set the initial value of the control defaultMenuIsOpen - set the initial open value of the menu defaultInputValue - set the initial value of the search input
Example of having props for both ways: value or defaultValue, depending on whether you want it to be controlled or not.