[Vote!]! means that the field (in this case votes) cannot return null and that it must resolve to an array and that none of the individuals items inside that array can be null. So [] and [{}] and [{foo: 'BAR'}] would all be valid (assuming foo is non-null). However, the following would throw: [{foo: 'BAR'}, null] [Vote]! means that the field cannot return null, but any individual item in the returned list can be null. [Vote!] means that the entire field can be null, but if it does return a value, it needs to an array and each item in that array cannot be null. [Vote] means that the entire field can be null, but if it does return a value, it needs to an array. However, any member of the array may also be null.

I could look into this more to understand where things are going wrong, if you can suggest to me which part of the way this is working might be off.

Besides that configuration, SvelteKit is just a normal Vite project that does rendering on both SSR and client-side.

Two wrongs don't make a right We should fix it in popper core. I sent a PR there: floating-ui/floating-ui#1342

Just import it the normal way. Then Vite can use the CJS version on the server-side and ESM version on the client-side. Forcing it to always be ESM breaks SSR with the latest SvelteKit.

The code isn't going back to the way it was So otherwise you'll be stuck on an old version forever...

Deeply importing Svelte components is not supported. Either import all components from one entrypoint, or always stick to deep imports, otherwise it could cause multiple instance of the Svelte library running.

So, underscores are not quite as good as spaces. They’re a compromise of language, readability, and semantics, but they’re the best we’ve got. Better than dashes, CamelCase, plus+signs, or anything else. So use them.

The “use spaces, or else fall back on quotes” system is just silly.

This post is like a year old... Does not matter ,

It allows you to access common components and utility modules without ../../../../ nonsense.

The difficulty is that the square brackets accessor doesn't allow a straightforward way to access items from the end of the array, and also doesn't accept a negative index.

function intersperse<T>(this: T[], mkT: (ix: number) => T): T[] { return this.reduce((acc: T[], d, ix) => [...acc, mkT(ix), d], []).slice(1); }

you might consider using Object.defineProperty to ensure the property is not enumerable:

A Map of root-level context key-value pairs to supply to the component

Tip for those who run into the same error message and find this bug report by Google: Your cause for this error message might be a different cause entirely. To find your cause, set a breakpoint, and look at the call stack.

We couldn't see the cause due to the horrific error message from Sapper. grr at Sapper.

Moving to devDependency worked, but why?

This means that underscores allow humans to be able to space out the words used, but computers lack the ability to do so.

This is because using hyphens instead of underscores makes it easier for Google’s web crawler to compute the information that your website has and create consistent results.

The product may not be compatible with routers or gateways with firmware that has been altered, is based on open source programs, or is non-standard or outdated

Just FYI, there is a nice way to "expect a change" in RSpec. You don't have to use it, what you have is fine, just thought I'd share. expect { widget.paper_trail.update_columns(name: "Bugle") }.to(change { widget.versions.length }).from(1).to(2)

I'd prefer a "guard clause" here. return unless enabled?

TylerRick commented

Wait, I'm still interested in a solution to this problem/need! (no activity doesn't necessarily = no interest. I totally understand if the maintainers just aren't interested in implementing this and would rather someone submit a PR... but would it have been any different if I'd pinged this thread every 5 months to show continued interest? )

To be more clear, it violates this particular rule.

For what it's worth, accessing attributes with [] is not the same as using send. The latter will call the accessor method, which is what you want 99/100.

The decision to use a "keep it clean" design for the user interface sometimes takes it a step too far.

The props used for each slot inside the Tooltip. Note that componentsProps.popper prop values win over PopperProps and componentsProps.transition prop values win over TransitionProps if both are applied.

If you want to restore the old behavior (thus not reaching level AA), you can apply the following diff: -<Tooltip> +<Tooltip disableInteractive> # Interactive tooltips no longer need the `interactive` prop. -<Tooltip interactive> +<Tooltip>

In order to work with Safari, you need at least one display block or flex item below the tooltip wrapper.

A co-operative card game about assembling flat-pack furniture with your partner, and definitely not about your collapsing relationship.

make you more prepared for spontaneous things in life, like when you get asked a question in the middle of nowhere, your brain usually freezes up and can't think of an answer. This game captures that entirely.

trying to counter the antivaccine movement predicted that antivaxxers would publicize and weaponize reports of death and adverse events after COVID-19 vaccines to give the impression that the vaccines are dangerous

When the embedded document has the same origin as the embedding page, it is strongly discouraged to use both allow-scripts and allow-same-origin, as that lets the embedded document remove the sandbox attribute — making it no more secure than not using the sandbox attribute at all.

Its good to know how to implement it. I would prefer to use a gem myself.

Fixing with containIf we give each article the contain property with a value of content, when new elements are inserted the browser understands it only needs to recalculate the containing element's subtree, and not anything outside it:

I’m talking about the adults flocking to school board meetings to protect children from the manufactured crisis of “critical race theory.”

There is so much good stuff going on here.

What a time to be alive!

The complex typewriting effect is abstracted away in a neat function, out of site and out of mind.

this action is re-usable. Anytime you want a typewriter effect added to an element, you just import the function and apply it. So elegant.

All that is left is use:typeWriter. You instantly understand what it does and so will probably any future colleagues.

Some call them the lifecycle methods of elements which I think is an apt description.

Actions are deceptively simple yet incredibly powerful.

Yep, we experimented with this, but what we found is that you loose most of Svelte's niceness like slots, and instead you'll pass around deeply nested objects.

Now this is getting too complex for discussing this here and these type of architectural decisions require more in depth understanding than what I can provide here.

My UIs are data/store driven. The UI is just a way to visualize the data. Your data could flow through all of of the extensions and the extensions can make decisions (e.g. setting visible to false). Like middlewares in a Connect/Express/Polka app. And the UI doesn't even know about all this, it just updates with the current state and makes sure it's consistent.

(you can get pretty far with <svelte:component> and passing component constructors around and spicing up props along the way)

Abstract the whole queryCommandState / execCommand system into a store (or some wrapper that also holds a store) that has state like isBold and canMakeBold and a makeBold() function.

You sure packed lot of good lessons and important concept explanations/illustrations into this little answer/tutorial. Well done.

The consumer component will barely change from our last example. The only difference is the way we'll get a reference to our store (since now the store is exported from the JS module):

In effect, the $ syntax we've seen above will actually setup a subscription to the store. And the subscription will be cancelled when the component is destroyed. If the store is subscribed by multiple components, the store will be disposed only when the last component unsubscribes (it will be reinitialized, if a new subscription is made). This is very handy to manage the lifecycle of disposable things in your code.

<!-- you can use the $ prefixed value directly in the template --> <!-- (so we actually don't need the reactive expression above, in this example)

lifecycle is also managed automatically by Svelte

(And we've covered 75% of the store topic... They're efficient, to the point... And simple!)

Now your whole WS logic can be encapsulated in your JS module. That makes for good separation of concern.

In order to use this, we need to use a little more advanced readable store. Here's your example updated for this:

In your Svelte component, you can then use your store with the special $ prefix syntax, to access the value of the store ('cause the temperature variable is a reference to the store itself, it's just a mean to our end, the result we need is the value):

// our temperature is now a store with initial value 0 const temperature = writable(0); // now we don't need to change this function, the change will be propaged // by the store itself const getTemperature = () => { return temperature; }

Here's how we would rewrite our callback example with a store instead:

Same as our callback example, except they offer a handful of other very useful tool (like computing derived values from other stores), and also a slick syntax in the Svelte component.

Stores are essentially some kind of simplified streams (or Observable as they're called in ES), that is they represent a value over time.

Stores are the idiomatic Svelte way when you need to import "reactivity" from your normal JS sources.

If you need to pass multiple arguments to an action, combine them into a single object, as in use:longpress={{duration, spiciness}}

Personally, I prefer an event-based communication, but I don't think it's actually better. The only problem with props is that it can cause problems if badly managed, but normally, both of them are ok. In real life, I would opt for storage.

Interim summary

Finally, I think Actions are great for animations, because you will definitely need to apply the same logic to many different elements. One of my favorite examples are FLIP animations, where a change in DOM position can be animated. For example shuffling a list of items. I will not dive deep into the topic in this article: I've written about some techniques in this article about FLIP animations in React and in this article about how to create spring animations with Web Animation API. Although they are not about Svelte, at the end of the day it all boils down to manipulating the HTML element directly. And Svelte Actions are a great place to do it.

We also need at least something in our CSS that can be set from outside. CSS custom properties are a great fit for this!

But you can get quite close to directly updating CSS with Actions!

export function autofocus(node) { node.focus(); } That's it. This is a legitimate Svelte Action!

To match against an ID or selectors that do not follow standard CSS syntax (by using a colon or space inappropriately, for example), you must escape the character with a backslash ("\"). As the backslash is also an escape character in JavaScript, if you are entering a literal string, you must escape it twice (once for the JavaScript string, and another time for querySelector()):

export interface TasksListSpecifics { 0: ('parallel' | 'sequential'); } export type TasksList = (string[] & TasksListSpecifics); Or more compact: export type TasksList = (string[] & { 0: ('parallel' | 'sequential'); }); The trick is to add your more specific properties on top of array of string type (Array<string>).

add ! to the end of the var that is being spread. E.g. [{}, ...payload!]

This also happens with an interface that fakes a tuple: interface Foo { 0: string; 1: number; 2?: boolean; // can't have an optional member in a real tuple }

Notice that in the else branch, we don’t need to do anything special - if x wasn’t a string[], then it must have been a string.

It might be confusing that a union of types appears to have the intersection of those types’ properties.

the name union comes from type theory. The union number | string is composed by taking the union of the values from each type. Notice that given two sets with corresponding facts about each set, only the intersection of those facts applies to the union of the sets themselves.

For example, if we had a room of tall people wearing hats, and another room of Spanish speakers wearing hats, after combining those rooms, the only thing we know about every person is that they must be wearing a hat.

Animal & { honey: boolean }

Extending a type via intersections

Type aliases and interfaces are very similar, and in many cases you can choose between them freely. Almost all features of an interface are available in type, the key distinction is that a type cannot be re-opened to add new properties vs an interface which is always extendable.

Inside each first-level directory of a MAFF archive, the second-level directory named ^metadata^ (case-sensitive) is reserved and should not contain actual content. A file or folder named ^metadata^ (case-insensitive) should not exist inside any first-level directory.

Support for reading and writing MAFF archives was provided in the Mozilla Application Suite, Firefox, and SeaMonkey thanks to the Mozilla Archive Format add-on from 2004 to 2018. While the original add-on is no longer maintained, the file format specification is still available and can be referenced by third-party software to provide better interoperability.

MAFF files are standard ZIP files containing one or more web pages, images, or other downloadable content. Additional metadata, like the original page address, is saved along with the content.

Unlike the related MHTML format, MAFF is compressed and particularly suited for large media files.

Docker Desktop remains free for small businesses (fewer than 250 employees AND less than $10 million in annual revenue), personal use, education, and non-commercial open source projects.It requires a paid subscription (Pro, Team or Business), starting at $5 per user per month, for professional use in larger businesses. You may directly purchase here, or share this post and our solution brief with your manager.While the effective date of these terms is August 31, 2021, there is a grace period until January 31, 2022 for those that require a paid subscription to use Docker Desktop.

Thanks to the positive support we received on the subscription updates, we’ve started working on Docker Desktop for Linux which is the second-most popular feature request in our public roadmap.

I received an Appraisal Award letter for a claim to have my roof replaced for a total amount of $16000. The insurance paid the first half of 9100 for the Actual Cash Value and stated that the difference which is the depreciation amount was going to get paid after the work gets completed. It was completed and now the insurance is stating that because the amount on the roofers bill was less than the total awarded amount that they won't pay the rest. I can either have the roofer send an itemized final bill to show the depreciation cost in addition to the first bill that didn't show the breakdown or additional costs... OR I shouldn't have to go through this because the awarded amount is due regardless because the job was completed as requested. I need help to recover my depreciation amount owed.

America's Frontline Doctors - a group she founded last year to speak out against the government's efforts to contain the coronavirus.

As a solo dev I find this review totally unfair and rude! This game has been made by one person and hundreds of hours have gone into it... To say 5 hours max has been put into this project is just a ignorant negative response.

Modern browsers that support the File System Access API (Edge and Chrome today) allow web pages to access the local file system (with your permission).

Like a lot of people who buy a .dev domain, we had no idea what we were going to do with it. And we certainly didn't anticipate that it would end up being the fulfillment of a mission over a decade in the making.

con: doesn't let you define after_transaction callbacks anywhere like ar_after_transaction does (outside of the after_commit, etc. callbacks which only happen at certain points in the model's life cycle)

.. isn't just a shell shortcut; it's a very real entry in the file system for the parent of the directory it is contained in.

So it actually replaces the file, not update? If that file is hard-linked, the the other link is unaffected?

It's all too complex for our little brains to handle. And like any situation of excess complexity, we collapse dimensions until we have a structure we can comprehend. The problem, in this case, is that our simplifications create tunnels large enough for the trucks of hacker to drive through—with ease.

As many have observed, login is a broken system. Until we can be identified by factors that are unique to our personhood (biometrics, etc.) that we don't have to remember or store somewhere, these problems will persist. People have too many passwords for too many accounts.

What consumers are now storing in cloud services encompasses the whole of their digital lives.

If you're looking for a slightly higher level API built on the same technology, you may want to check out watir or capybara.

I don't see how making the attribute selectively present (and unlike anything else) achieves that goal.

Content in the wild can easily come to rely on this: var underAutomation = ("webdriver" in navigator) ? navigator.webdriver : false; v, without this behaviour: var underAutomation = navigator.webdriver;

to be always exposed with value true|false since there was no real benefit (privacy, implementation ease, performance, or otherwise) to making its existence conditional.

to be always exposed with value true|false since there was no real benefit (privacy, implementation ease, performance, or otherwise) to making its existence conditional.

With firefox 88 it won't work anymore, now navigator.webdriver is always true when maionette is enabled.

profile = webdriver.FirefoxProfile() profile.set_preference("dom.webdriver.enabled", False) profile.set_preference('useAutomationExtension', False) profile.update_preferences()

Honestly, I don't know. Strictly speaking it's different to a window being opened at a specific size (I can see the difference). I don't know whether that difference is material. Seeing as these are tests, I'd like to remove as many unknowns as possible. If someone can tell me that it makes no difference then I'd be happy.

Worst practices

Info for maintainers Triage this issue by using labels. If information is missing, add a helpful comment and then I-issue-template label. If the issue is a question, add the I-question label. If the issue is valid but there is no time to troubleshoot it, consider adding the help wanted label. After troubleshooting the issue, please add the R-awaiting answer label. Thank you!

But it is kind of verbose, and it’s also a lot slower, so I can understand why the model test might be preferred.

If and when you need some kind of behaviour that waits for things, wait_until is a giant big sledgehammer. There are more fine grained, sophisticated tools built into Capybara, and I want you to learn about them, because those are some of the best features of the library. And when the built in tools aren’t enough, there are more sophisticated tools available than that clunky hammer. So hopefully the removal of wait_until encourages you to write better tests.

I am firmly convinced that asserting on the state of the interface is in every way superior to asserting on the state of your model objects in a full-stack test.

Even if #foo is originally on the page and then removed and replaced with a #foo which contains baz after a short wait, Capybara will still figure this out.

The release of Capybara 2.0.0 removed the wait_until method from the API. This seems to have frustrated a few people,

so let me explain why this decision was reached and what your options are for the future.

wait_until was removed for several reasons:

As long as you stick to the Capybara API, and have a basic grasp of how its waiting behaviour works, you should never have to use wait_until explicitly.

Let’s make that really clear, Capybara is ridiculously good at waiting for content.

apybara could have easily figured out how to wait for this content, without you muddying up your specs with tons of explicit calls to wait_until. Our developer could simply have done this: page.find("#foo").should have_content("login failed")

Now after a long debugging session, our developer has found the timing issue. They now realize that there is a wait_until method in the API, and immediately think that, "hey, this sounds like what I need!"

Its existence confuses people into thinking that it is necessary, when in fact it isn’t.

TylerRick

I can't blame you. This problem seems anything but a newbie question! I was surprised when I noticed that this post (which was the only post I could find about trying to use chromedriver with flatpak chromium) in the linux4noobs forum. I've been using Linux as my primary desktop for ~15 years and this problem has stumped me too.

Actually, I ended up uninstalling Chrome and installing a chromium deb. Since no chromium deb exists in Ubuntu or Pop OS repositories anymore, I followed the instructions from https://askubuntu.com/questions/1204571/how-to-install-chromium-without-snap to add the Debian stable repo and install Chromium from there instead.

I'm having this problem too. Trying to use chromedriver with com.github.Eloston.UngoogledChromium (also tried org.chromium.Chromium) on Pop!_OS and selenium/webdriver (I'm using it with Ruby/capybara).This was the only post I could find (so far) about using chromedriver with a flatpak chrome/chromium... I wish someone would answer how or if this is possible.I created a chrome wrapper script that launches the flatpak, so that I could point to the script as my binary location. Did you do the same?It manages to open a window but the window is empty, and it just hangs for a hwile, and then eventually fails with:unknown error: DevToolsActivePort file doesn't exist (Selenium::WebDriver::Error::UnknownError) Any ideas how to get it working? I'd rather not install the "official" (proprietary software) Chrome binary on my system.Like you said, I never had any problems back in the good old days when we had deb packages for chromium. But now that we have to use a flatpak, I wonder if that's what the problem is — maybe chromedriver can't communicate directly with the chrome process because it is isolated/containerized??

As soon as I installed a Chrome deb everything worked.sudo dpkg -i \~/Downloads/google-chrome-stable\_current\_amd64.deb It's unfortunate that that's the only way I could get it to work.

Could someone guide me how to set up chromedriver with selenium using chromium flatpak properly? I can't seem to find any tutorial doing it like this... I never had issues with chromedriver using the "old" sudo apt way and I also got it working using snapd. But since I am using Pop!_OS I'd like to just use flatpaks if there is no sudo apt repo.

apt-rdepends exists. This functionality should really reside in apt-cache itself.

take advantage of LVM snapshots. Take snapshots before and after an upgrade. In case, if the system is in unrecoverable position, rollback to the last snapshot from a system rescue LiveCD. A useful program for this, as well as regular system backups is timeshift

Although Flatpak is similar to Snap, I think it matches the freedom standards that many Linux users are usually looking for, much better than Snap.

the snap-based chromium cannot access files on my separately-mounted /opt filesystem. The non-snap chromium has no such limitation. Until or unless the snap version ever is able to access all the filesystems on my device, I am willing to live with the risk of a PPA-based version.

Perhaps not a good idea, in general, to use a random PPA for such sprawling software as a browser. Auditability near zero even if it is open source.

I might just leave it installed, in case Canonical ends up replacing more important deb packages with snaps. (I might also drop Ubuntu if they do that.) As long as there isn't a snap directory cluttering my home dir, I can tolerate snapd lurking in the background for now.

This is actively being worked on - for those interested you can follow the progress in https://github.com/snapcore/snapd/pull/10836

Seeing how this has been treated for 4.5 years makes this seem like a pretty dysfunctional project. Please have mercy on your poor users and fix this.

After 5 years there's still no fix. This is so annoying. I'm now getting rid of all snap packages and installing deb variants instead. Finally I'll purge snap and if these weird decisions keep on going I'll also move to another distro. Common Canonical. Seriously?

In order to prevent this PR from becoming too large to review, I left the spread test, the part of this feature which makes it work with user daemons (left a TODO) and the addition of ~/Snap, for follow-up PRs.

I find some of XDG's default dirs, especially ~/.local/share/whatever, to be very annoying. (Almost as annoying as having ~/snap polluting my home dir, but for a different reason.) I shouldn't have to type such long paths or navigate three folders deep in order to access my data files. I therefore make use of the XDG_DATA_HOME environment variable for XDG-style programs, so they will put my files somewhere convenient. However, I don't think Snap can honor that variable, because AppArmor rules require fixed paths. Given 1 & 2, I think ~/.snap/data is a sensible compromise, at least until the underlying components are flexible enough to let the user choose.

Calling a software convention "pretty 90s" somewhat undermines your position. Quite a lot of well-designed software components are older than that. If something is problematic, it would be more useful to argue its faults. When someone cites age to justify change, I usually find that they're inexperienced and don't fully understand the issues or how their proposed change would impact other people.

I hope you all will forgive my intrusion as a non-maintainer. Here's a perspective as a user: