This is a question related to the Rust reactive WASM framework.
Here is the code (putting the style! component within the view function of the class component produces the same error). This example is taken from the example page here (https://docs.rs/yew-style-in-rs/latest/yew_style_in_rs/)
use yew::prelude::*;
use yew_style_in_rs::*;
#[function_component]
pub fn Mdpages() -> Html {
style! {
let css = css! {r#"
border: solid green 1px;
width: 100%;
height: 150px;
text-align: center;
box-sizing: border-box;
& > p {
background: white;
}
"#};
}
html!{
<div class={classes!(css)}>
<p>{"compile time static css"}</p>
</div>
}
}
And here is the error -
error[E0277]: the trait bound `Classes: From<yew_style_in_rs::css::StyleId>` is not satisfied
--> src/pages/mdpages.rs:22:34
|
22 | <div class={classes!(css)}>
| ^^^ the trait `From<yew_style_in_rs::css::StyleId>` is not implemented for `Classes`
|
= help: the following other types implement trait `From<T>`:
<Classes as From<&'static str>>
<Classes as From<&Option<T>>>
<Classes as From<&String>>
<Classes as From<&[T]>>
<Classes as From<Cow<'static, str>>>
<Classes as From<Option<T>>>
<Classes as From<String>>
<Classes as From<Vec<T>>>
= note: required for `yew_style_in_rs::css::StyleId` to implement `Into<Classes>`
note: required by a bound in `Classes::push`
--> /Users/peterweyand/.cargo/registry/src/github.com-1ecc6299db9ec823/yew-0.20.0/src/html/classes.rs:58:20
|
58 | pub fn push<T: Into<Self>>(&mut self, class: T) {
| ^^^^^^^^^^ required by this bound in `Classes::push`
Some errors have detailed explanations: E0277, E0423.
For more information about an error, try `rustc --explain E0277`.
warning: `yew_page` (lib) generated 4 warnings
error: could not compile `yew_page` due to 2 previous errors; 4 warnings emitted
2023-02-05T03:08:40.774108Z ERROR ❌ error
error from HTML pipeline
Caused by:
0: error from asset pipeline
1: error during cargo build execution
2: cargo call returned a bad status
2023-02-05T03:08:40.774976Z INFO 📡 serving static assets at -> /
2023-02-05T03:08:40.775031Z INFO 📡 server listening at http://127.0.0.1:8080
This is as simple an example as I can make and I don't know why the error is occurring. I've found a workaround by including a hashmap of styles that I can import inside class components, but it's a bit clunky. Here is my Cargo.toml - maybe that's the issue, but I've imported yew_style_in_rs -
[package]
name = "yew_page"
version = "0.1.0"
edition = "2021"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
route = "0.2.0"
yew = { version = "0.20.0", features = ["csr"] }
yew-router = "0.17.0"
reqwest = "0.11.14"
wasm-logger = "0.2.0"
log = "0.4.17"
gloo-net = "0.2.5"
wasm-bindgen-futures = "0.4.33"
wasm-bindgen = "0.2.83"
js-sys = "0.3.60"
yew-style-in-rs = "0.4.1"
[dependencies.web-sys]
version = "0.3"
features = [
"Headers",
"Request",
"RequestInit",
"RequestMode",
"Response",
"Window",
'HtmlCanvasElement',
'WebGlBuffer',
'WebGlProgram',
'WebGlRenderingContext',
'WebGlShader',
'WebGlUniformLocation',
]
[[bin]]
name = "yew_page"
required-features = ["yew/csr"]
Here is the link to the github question - https://github.com/yewstack/yew/issues/3115
I took a moment to clone the yew-style-in-rs repository and verify the examples.
They appear to work, but depend on yew = "0.19.3".
Trying to use yew = { version = "0.20.0", features = ["csr"] } with minimal changes as required by the newer Yew api gave me errors similar to the ones you see.
I also opened issues/10 there.
futursolo also reports
This is due to yew_styles_in_rs does not support Yew v0.20. yew_styles_in_rs needs to be upgraded to support Yew v0.20 or you need to use Yew v0.19 with yew_styles_in_rs.
So I suspect you probably need to do one of
use the older yew = "0.19.3"
wait until yew-style-in-rs supports yew = {version="0.20.0",features=["csr"]}
figure out how to update yew-style-in-rs (and submit a patch) or
don't use yew-style-in-rs and just put your css in your own components
Looking at what this offers I'd probably do 4. and do my own css, but if I really liked this approach and I needed something asap I'd do 3. or 1. If there's no rush I'd do 2.
Related
I am trying to understand the solana/example-helloworld by re-writing the rust lib myself. I have done this and from the package.json file, to generate the .so file, following is what is run:
cargo build-bpf --manifest-path=./src/program-rust/Cargo.toml --bpf-out-dir=dist/program
I used above since I already have cargo setup locally and run above against my setup, I faced a few issues, from the edition (was using 2021, had to downgrade to 2018) to having to rename main.rs to lib.rs and others I can't remember.
Below is my actual running command from the terminal in the project root directory where the Cargo.toml file is in:
cargo build-bpf --manifest-path=./Cargo.toml --bpf-out-dir=dist/program
But upon running above, in the dist directory, there is nothing
This is actually a multi-tied question:
.so file are signifies solana files, right?
What do we mean by cargo build-bpf?
Is there any reason, why 2021 edition didn't work for the solana example?
Finally, why does the above command not output my .so file?
My Cargo.toml below:
[package]
name = "jjoek-sc"
version = "0.0.1"
description = "My first rust program for solana (hello john)"
authors = ["JJoek <info#jjoek.com>"]
license = "Apache-2.0"
homepage = "https://jjoek.com/"
edition = "2018"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
borsh = "0.9.1"
borsh-derive = "0.9.1"
solana-program = "~1.8.14"
Below is my lib.rs
use borsh::{BorshDeserialize, BorshSerialize};
use solana_program::{
account_info::{next_account_info, AccountInfo},
entrypoint,
entrypoint::ProgramResult,
pubkey::Pubkey,
msg,
program_error::ProgramError,
};
/// Define the type of state stored in accounts
#[derive(BorshSerialize, BorshDeserialize, Debug)]
pub struct GreetingAccount {
/// number of greetings
pub counter: u32,
}
// Declare and export the program's entrypoint
entrypoint!(process_instruction);
// Program entrypoint's implementation
pub fn process_instruction(program_id: &Pubkey, accounts: &[AccountInfo], _instruction_data: &[u8]) -> ProgramResult {
msg!("Hello, John everything is gonna be okay");
msg!("Hello World Rust program entrypoint");
// Iterating accounts is safer than indexing
let accounts_iter = &mut accounts.iter();
// Get the account to say hello to
let account = next_account_info(accounts_iter)?;
// The account must be owned by the program in order to modify its data
if account.owner != program_id {
msg!("Greeted account does not have the correct program id");
return Err(ProgramError::IncorrectProgramId);
}
// Increment and store the number of times the account has been greeted
let mut greeting_account = GreetingAccount::try_from_slice(&account.data.borrow())?;
greeting_account.counter += 1;
greeting_account.serialize(&mut &mut account.data.borrow_mut()[..])?;
msg!("Greeted {} time(s)!", greeting_account.counter);
Ok(())
}
.so file are signifies solana files, right?
so stand for shared object, also known as a dynamically relocatable library or dylib in Cargo.toml.
What do we mean by cargo build-bpf?
BPF is a virtual machine inside the kernel, so this should instruct cargo to build for that target.
Is there any reason, why 2021 edition didn't work for the solana example?
I don't know, but I suspect it's a simple fix.
Finally, why does the above command not output my .so file?
Could it be that you are missing the lib section in Cargo.toml:
[lib]
crate-type = ["cdylib", "lib"]
If you look at the Tokio docs on docs.rs there's a blue tag indicating that a feature must be activated in order to access this API:
I would like to enable this for my crate as well, how can this be done?
The bad news is: It's a nightly-only feature for now.
The good news is: docs.rs uses nightly by default.
To get this to work all you need is to enable the doc_cfg feature and apply #doc(cfg) to the item being documented
#![feature(doc_cfg)]
#[doc(cfg(feature = "macros"))]
pub fn test() {}
Because this is a nightly-only feature, you probably don't want to enable it all the time. tokio defines the following in its Cargo.toml to only enable this feature on docs.rs:
# docs.rs-specific configuration
[package.metadata.docs.rs]
# document all features
all-features = true
# defines the configuration attribute `docsrs`
rustdoc-args = ["--cfg", "docsrs"]
and then they use
// only enables the `doc_cfg` feature when
// the `docsrs` configuration attribute is defined
#![cfg_attr(docsrs, feature(doc_cfg))]
#[cfg_attr(docsrs, doc(cfg(feature = "macros")))]
pub fn test() {}
In the latest nightly (since v1.57 maybe), you can use feature doc_auto_cfg (merged in PR#90502) and you no longer need to manually mark features for doc, just write cfg as before:
#![feature(doc_auto_cfg)]
#[cfg(feature = "macros")]
pub fn test() {}
To check it locally, run cargo +nightly doc --all-features.
If you want to continue using stable for commands other than cargo doc, you can:
#![cfg_attr(doc, feature(doc_auto_cfg))]
#[cfg(feature = "macros")]
pub fn test() {}
UPDATE: The above method still requires doc-tests to run nightly, and it also requires dependents' doc command to run nightly. A workaround is that we can enable the doc_auto_cfg feature only under nightly.
In Cargo.toml, adding:
[build-dependencies]
rustc_version = "0.4.0"
Create a build.rs file with the following contents:
use rustc_version::{version_meta, Channel};
fn main() {
// Set cfg flags depending on release channel
let channel = match version_meta().unwrap().channel {
Channel::Stable => "CHANNEL_STABLE",
Channel::Beta => "CHANNEL_BETA",
Channel::Nightly => "CHANNEL_NIGHTLY",
Channel::Dev => "CHANNEL_DEV",
};
println!("cargo:rustc-cfg={}", channel)
}
Then we can enable the feature doc_auto_cfg this way:
#![cfg_attr(all(doc, CHANNEL_NIGHTLY), feature(doc_auto_cfg))]
Since docs.rs uses nightly by default, the documentation on there will be shown as you expected.
I am a newbie of rust, when I tried to write a rust web api, but the project contains hyphen so I could not use it, if the project name like diesel_demo , I could use it like this:
use diesel_demo::schema::posts::dsl::*;
but if my project name like diesel-demo, what should I do to use it? I can not change my project name now with hyphen reddwarf-music. I read the docs and tell me the cargo will trans the - to _ by default, so I am use it like this:
use reddwarf_music::schema::posts::dsl::*;
but shows error like this:
~/Documents/GitHub/reddwarf-music on develop! ⌚ 17:56:51
$ cargo build ‹ruby-2.7.2›
Compiling hello-rocket v0.1.0 (/Users/dolphin/Documents/GitHub/reddwarf-music)
error[E0433]: failed to resolve: use of undeclared crate or module `reddwarf_music`
--> src/biz/music/music.rs:1:5
|
1 | use reddwarf_music::schema::posts::dsl::*;
| ^^^^^^^^^^^^^^ use of undeclared crate or module `reddwarf_music`
what should I do handle the - in rust? By the way the scheme is generate in my local src, not from third package. This is my project structure:
this is my Cargo.toml:
[package]
name = "reddwarf_music"
version = "0.1.0"
edition = "2018"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
rocket = { version = "0.5.0-rc.1", features = ["json"] }
rand = "0.8.4"
serde = { version = "1.0.64", features = ["derive"] }
serde_json = "1.0.64"
reqwest = "0.11.4"
# database
diesel = { version = "1.4.4", features = ["postgres"] }
dotenv = "0.15.0"
Within a crate you don't use the crates name with use, rather, you refer to the crate itself using the identifier crate.
So inside your crate "reddwarf-music", when you want to use an internal symbol, instead of writing
use reddwarf_music::schema::posts::dsl::*;
you write
use crate::schema::posts::dsl::*;
If you look at the Tokio docs on docs.rs there's a blue tag indicating that a feature must be activated in order to access this API:
I would like to enable this for my crate as well, how can this be done?
The bad news is: It's a nightly-only feature for now.
The good news is: docs.rs uses nightly by default.
To get this to work all you need is to enable the doc_cfg feature and apply #doc(cfg) to the item being documented
#![feature(doc_cfg)]
#[doc(cfg(feature = "macros"))]
pub fn test() {}
Because this is a nightly-only feature, you probably don't want to enable it all the time. tokio defines the following in its Cargo.toml to only enable this feature on docs.rs:
# docs.rs-specific configuration
[package.metadata.docs.rs]
# document all features
all-features = true
# defines the configuration attribute `docsrs`
rustdoc-args = ["--cfg", "docsrs"]
and then they use
// only enables the `doc_cfg` feature when
// the `docsrs` configuration attribute is defined
#![cfg_attr(docsrs, feature(doc_cfg))]
#[cfg_attr(docsrs, doc(cfg(feature = "macros")))]
pub fn test() {}
In the latest nightly (since v1.57 maybe), you can use feature doc_auto_cfg (merged in PR#90502) and you no longer need to manually mark features for doc, just write cfg as before:
#![feature(doc_auto_cfg)]
#[cfg(feature = "macros")]
pub fn test() {}
To check it locally, run cargo +nightly doc --all-features.
If you want to continue using stable for commands other than cargo doc, you can:
#![cfg_attr(doc, feature(doc_auto_cfg))]
#[cfg(feature = "macros")]
pub fn test() {}
UPDATE: The above method still requires doc-tests to run nightly, and it also requires dependents' doc command to run nightly. A workaround is that we can enable the doc_auto_cfg feature only under nightly.
In Cargo.toml, adding:
[build-dependencies]
rustc_version = "0.4.0"
Create a build.rs file with the following contents:
use rustc_version::{version_meta, Channel};
fn main() {
// Set cfg flags depending on release channel
let channel = match version_meta().unwrap().channel {
Channel::Stable => "CHANNEL_STABLE",
Channel::Beta => "CHANNEL_BETA",
Channel::Nightly => "CHANNEL_NIGHTLY",
Channel::Dev => "CHANNEL_DEV",
};
println!("cargo:rustc-cfg={}", channel)
}
Then we can enable the feature doc_auto_cfg this way:
#![cfg_attr(all(doc, CHANNEL_NIGHTLY), feature(doc_auto_cfg))]
Since docs.rs uses nightly by default, the documentation on there will be shown as you expected.
If you look at the Tokio docs on docs.rs there's a blue tag indicating that a feature must be activated in order to access this API:
I would like to enable this for my crate as well, how can this be done?
The bad news is: It's a nightly-only feature for now.
The good news is: docs.rs uses nightly by default.
To get this to work all you need is to enable the doc_cfg feature and apply #doc(cfg) to the item being documented
#![feature(doc_cfg)]
#[doc(cfg(feature = "macros"))]
pub fn test() {}
Because this is a nightly-only feature, you probably don't want to enable it all the time. tokio defines the following in its Cargo.toml to only enable this feature on docs.rs:
# docs.rs-specific configuration
[package.metadata.docs.rs]
# document all features
all-features = true
# defines the configuration attribute `docsrs`
rustdoc-args = ["--cfg", "docsrs"]
and then they use
// only enables the `doc_cfg` feature when
// the `docsrs` configuration attribute is defined
#![cfg_attr(docsrs, feature(doc_cfg))]
#[cfg_attr(docsrs, doc(cfg(feature = "macros")))]
pub fn test() {}
In the latest nightly (since v1.57 maybe), you can use feature doc_auto_cfg (merged in PR#90502) and you no longer need to manually mark features for doc, just write cfg as before:
#![feature(doc_auto_cfg)]
#[cfg(feature = "macros")]
pub fn test() {}
To check it locally, run cargo +nightly doc --all-features.
If you want to continue using stable for commands other than cargo doc, you can:
#![cfg_attr(doc, feature(doc_auto_cfg))]
#[cfg(feature = "macros")]
pub fn test() {}
UPDATE: The above method still requires doc-tests to run nightly, and it also requires dependents' doc command to run nightly. A workaround is that we can enable the doc_auto_cfg feature only under nightly.
In Cargo.toml, adding:
[build-dependencies]
rustc_version = "0.4.0"
Create a build.rs file with the following contents:
use rustc_version::{version_meta, Channel};
fn main() {
// Set cfg flags depending on release channel
let channel = match version_meta().unwrap().channel {
Channel::Stable => "CHANNEL_STABLE",
Channel::Beta => "CHANNEL_BETA",
Channel::Nightly => "CHANNEL_NIGHTLY",
Channel::Dev => "CHANNEL_DEV",
};
println!("cargo:rustc-cfg={}", channel)
}
Then we can enable the feature doc_auto_cfg this way:
#![cfg_attr(all(doc, CHANNEL_NIGHTLY), feature(doc_auto_cfg))]
Since docs.rs uses nightly by default, the documentation on there will be shown as you expected.