Ignatiy2

Попробуйте изменить var markup таким образом:

var markup = new ReplyKeyboardMarkup(list, resizeKeyboard=True);

Подробнее в документации

upd by Ignatiy2

Это Файлы подсказки для разработки. Посмотрите в их структуру. В общем удаляйте без проблем, кстати при публикации они не должны попадать в папку сборки

Просто апи в случае single page application, или веб сервиса без ui.
MVC если хочется быстро сделать сайт с формами.

Но граница очень размыта, знать одно и не знать другого, практически невозможно, и вопрос становится бессмысленным.
Это разделение было сделано когда-то просто чтобы было 2 шаблона проекта в visualstudio, так что не советую на этом концентрироваться а изучать aspnetcore в целом

Почитайте про асинхронность тут.Её задача сократить задержки

Не знаю насколько это противоречит паттерну, но с ходу пришло такое решение.

View:

<Button x:Name="MyButton" Command="{Binding ClickCommand}" 
CommandParameter="{Binding ElementName=MyButton}"/>

ViewModel:

public class MainViewModel : BaseViewModel
{
    public Command ClickCommand { get; set; }

    public MainViewModel()
    {
        ClickCommand = new Command(ClickCommandExecute);
    }

    private void ClickCommandExecute(object obj)
    {
        Button button = obj as Button;
        MessageBox.Show(button.ActualHeight.ToString() + " : " + button.ActualWidth);
    }
}

Только тсссссс! ViewModel ни слова!

Зависит от того зачем вам нужна информация о размерах UI - элементов.

Если это часть пользовательских настроек, то хранить их на уровне ViewModel совершенно нормально и никак не противоречит паттерну.

Но если это нужно исключительно для временной настройки UI, то и код должен находится на уровне View.

Для вашего примера решение будет таким: добавьте обработчик события клика на кнопку и выводить информацию там.

MVVM это не означает что в code-behind не должно быть никакого кода. Это типичная ошибка. В .xaml.cs не должно быть того, что не относится непосредственно к отображению.

Управление анимацией, вывод вспомогательных сообщений, кастомизация пользовательских элементов управления - все это может быть там.

Я не эксперт, но возможно событие GotFocus срабатывает раньше, чем присваивается значение выделенному элементу SelectedItem.

Решить можно так.

Помимо библиотеки interactivity подключите библиотеку interactions:

xmlns:i="http://schemas.microsoft.com/expression/2010/interactivity"
xmlns:ei ="http://schemas.microsoft.com/expression/2010/interactions"

Подключение события будет выглядеть вот так:

<i:Interaction.Triggers>
    <i:EventTrigger EventName="GotFocus">
        <ei:CallMethodAction MethodName="NoteList_GotFocus"
                             TargetObject="{Binding }"/>
    </i:EventTrigger>
</i:Interaction.Triggers>

ViewModel:

public void NoteList_GotFocus(object sender, RoutedEventArgs e)
{
    if (e.OriginalSource is ListBoxItem lvi)
    {
        Note note = lvi.DataContext as Note;
        MessageBox.Show(note.Title);
    }
}

Доказательство:

Попробуйте вот так

if(CurrentContentVM is WatchNoteVM wnVM && wnVM.WatchNote == deleteNote)

Можно установить в качестве панели UniformGrid, тогда все строки будут иметь одинаковую высоту.

<ListBox Grid.Column="1" ItemsSource="{Binding Notes}">
    <ItemsControl.ItemsPanel>
        <ItemsPanelTemplate>
            <UniformGrid Columns="1" />
        </ItemsPanelTemplate>
    </ItemsControl.ItemsPanel>
    <ItemsControl.ItemTemplate>
        <DataTemplate>
            <TextBlock Text="{Binding Title}" />
        </DataTemplate>
    </ItemsControl.ItemTemplate>
</ListBox>

За идею спасибо Athari

Вместо:

<TextBox Text="{Binding ElementName=NewNote,Path=Title,UpdateSourceTrigger=PropertyChanged}"/>

делаем:
<TextBox Text="{Binding NewNote.Title}"/>

В чем разница?

1. ElementName означает, что в качестве источника данных будет не ViewModel, а экранный элемент с указанным именем.

2. UpdateSourceTrigger=PropertyChanged — это значение по умолчанию, его указывать не обязательно.

Возможно вам подойдет такой вариант:

<Window.Resources>
    <ContextMenu x:Key="MyContextMenu">
        <!--Ваше меню -->
    </ContextMenu>
</Window.Resources>

<Grid>
     <!-- колонки строки -->
    <TextBox Tag="1" Grid.Column="1" Grid.Row="5" ContextMenu="{StaticResource MyContextMenu}"/>        
    <TextBox Tag="2" Grid.Column="2" Grid.Row="5" ContextMenu="{StaticResource MyContextMenu}"/>                   
</Grid>

Используйте свойство MinWidth у класса Window, а не Button.

Порталы

1. Вам надо научиться работать в связке Apache/Nginx + PHP. Кроссдоменные запросы нельзя делать из файлов открытых как "file:///"
2. В React-компонент никак. В шаблон к которому крепится React-приложение можно.

Ты делаешь напрямую запросы к файлу, который лежит на диске. По крайней мере, если судить по вот этой ошибке Access to XMLHttpRequest at 'file:///C:/Users/%D0%9E%D0%BB%D0%B5%D0%B3/esktop/React+Redux/new-react/public/update.php'. Так не прокатит.

Тебе надо веб-сервер настроить (Nginx или Apache, например), а также настроить интерпретатор php. Запросы из React делать надо к серверу, а не к файлу на жестком диске. То есть урл для запросов у тебя будет типа такого: 127.0.0.1/update.php.

Вам нужен роутинг. При переходе на страницу blog/articles/?slug=first-article вы берете гет параметр slug, ищите по нему в базе статью и выводите все так же циклом в шаблоне.

jQuery отличный инструмент и я не перестану об этом говорить. Кто бы там не хейтил, jQuery говно, юзайте нативный js, он уже всё может и т.п(чаще всего - это молодёж, которая пишет на react или vue, angular!!! Ясен хер там не нужен jquery). Дайте этим людям написать одинаковые проекты, что бы 1 писал на ваниле, а другой на jquery, я посмотрю на те решения, что были придуманы на ваниле, когда в jquery это решается 1м методом. Поверьте, врятли результат можно будет сопоставить. Не просто же так на крутых и новомодных проектах все юзают транспиляторы для того, что бы новый новый синтаксис и фичи перевести в код старого формата!!! Потому что веб не готов ещё в полной мере юзать все новшества, что приходят в js.

Ребята из бутстрап тоже пошли вперёд планеты всей и переписывают свой фреймворк на нативный js. Несколько лет уже переписывают и были статьи, как же они охерели, что всё не так просто, как кажется)))

Всё что jquery и делает так это работа с DOM и ajax по сути своей, всё остальное - это мелочи по большей части не использующиеся. jQuery был и остаётся пока ещё, при условие всяких там ES10-20-40 фаворитом при создании обычных сайтиков, просто тупо он решает множество вопросов кроссбраузерности и его работа с DOM в разы удобнее нативной.

Да, он не предназначен для прокладывания или создания как-то крутой архитектуры и создания сайтов на по типу SPA. Он не для этого создан и не эти задачи решает. Используя его для подобных вещей вы в полной мере закопаете себя в куче известной субстанции.

Насчёт быстродействия - я никогда не замечал жутчайших лагов или прочих тормозов при использовании jquery.
Любая массивная работа с DOM по историческим причинам накладна для браузера. Но для того, что бы кликать и показывать окошки, скрывать\показывать блоки, отправлять формочки, то jQuery делает это без каких либо проблем и без всяких лагов.

Для массивной работы с DOM, обновлением контента через ajax или работы с огромными массивами данных на стороне фронта лучше использовать специальные фреймворки на по типу react, vue и т.п.

На фрилансе, при создании сайтиков я юзал и буду пока что юзать jquery как решение, которое сразу же отметает кучу проблем.

Учитесь определять объёмы и целесообразность использования тех или иных библиотек для ваших задач.
Если вам нужно лишь сделать пару кликов на кнопки что бы показать красивое окошко, то jquery не обязательно юзать.