Como definir variables ​​javascript usando o MVC4 com o Razor

Alguém pode formatar o código abaixo para que eu possa definir variables ​​srcript com código c # usando razor?

O abaixo não funciona, eu tenho assim que é fácil para alguém ajudar.

@{int proID = 123; int nonProID = 456;}  @{  var nonID =@nonProID; var proID= @proID; window.nonID = @nonProID; window.proID=@proID;  }  

Estou recebendo um erro de tempo de design

insira a descrição da imagem aqui

Você deve dar uma olhada na saída que sua página de razor está resultando. Na verdade, você precisa saber o que é executado pelo server-side client-side . Tente isto:

 @{ int proID = 123; int nonProID = 456; }  

A saída deve ser assim:

insira a descrição da imagem aqui

Dependendo de qual versão do Visual Studio você está usando, aponte alguns destaques no tempo de design para exibições com razor.

Foi assim que resolvi o problema:

 @{int proID = 123; int nonProID = 456;}  

É auto-documentável e não envolve conversão de e para texto.


Nota: tenha cuidado ao usar a function Number() não criar new Number() objects new Number() – pois o operador exatamente igual pode se comportar de uma maneira não óbvia:

 var y = new Number(123); // Note incorrect usage of "new" var x = new Number(123); alert(y === 123); // displays false alert(x == y); // displays false 

Como erros de syntax de razor podem se tornar problemáticos enquanto você está trabalhando na visualização, eu entendo totalmente por que você gostaria de evitá-los. Aqui estão algumas outras opções.

  

As citações funcionam como delimitadores, portanto, o analisador de lâminas é feliz. Mas é claro que o seu C # int se torna uma string JS na primeira instrução. Para os puristas, a segunda opção pode ser melhor.

Se alguém tiver uma maneira melhor de fazer isso sem os erros de syntax de razor, em particular mantendo o tipo do var, eu adoraria ver isso!

Eu vi várias abordagens para trabalhar em torno do bug, e eu corri alguns testes de tempo para ver o que funciona para a velocidade ( http://jsfiddle.net/5dwwy/ )

Abordagens:

  1. Atribuição direta

    Nesta abordagem, a syntax de razor é diretamente atribuída à variável. Isso é o que lança o erro. Como linha de base, o teste de velocidade do JavaScript simplesmente faz uma atribuição direta de um número a uma variável.

  2. Passe pelo construtor `Number`

    Nesta abordagem, envolvemos a syntax de razor em uma chamada ao construtor `Number`, como em` Number (@ ViewBag.Value) `.

  3. ParseInt

    Nessa abordagem, a syntax do razor é colocada dentro de aspas e passada para a function `parseInt`.

  4. Função de retorno de valor

    Nesta abordagem, é criada uma function que simplesmente usa a syntax de razor como parâmetro e a retorna.

  5. Função de verificação de tipo

    Nesta abordagem, a function executa uma verificação básica de tipo (procurando null, basicamente) e retorna o valor se não for null.

Procedimento:

Usando cada abordagem mencionada acima, um for-loop repete cada chamada de function 10M vezes, obtendo o tempo total para o loop inteiro. Então, esse loop for é repetido 30 vezes para obter um tempo médio por ação de 10M. Esses tempos foram então comparados entre si para determinar quais ações eram mais rápidas do que outras.

Observe que, como o JavaScript está em execução, os números reais que outras pessoas recebem serão diferentes, mas a importância não está no número real, mas como os números se comparam aos outros números.

Resultados:

Usando a abordagem de atribuição direta, o tempo médio para processar 10M atribuições foi de 98,033ms. Usando o construtor Number rendeu 1554,93ms por 10M. Da mesma forma, o método parseInt levou 1404.27ms. As duas chamadas de function levaram 97.5ms para a function simples e 101.4ms para a function mais complexa.

Conclusões

O código mais limpo para entender é a atribuição direta. No entanto, devido ao bug no Visual Studio, isso relata um erro e pode causar problemas com o Intellisense e dar uma sensação vaga de estar errado.

O código mais rápido foi a chamada de function simples, mas apenas por uma pequena margem. Como não fiz mais análises, não sei se essa diferença tem significância estatística. A function de verificação de tipo também foi muito rápida, apenas um pouco mais lenta que uma atribuição direta, e inclui a possibilidade de que a variável possa ser nula. Não é realmente prático, porque mesmo a function básica retornará indefinida se o parâmetro for indefinido (nulo na syntax de razor).

Analisar o valor da razor como um int e executá-lo através do construtor era extremamente lento, na ordem de 15x mais lenta que uma atribuição direta. O mais provável é que o construtor Number esteja, na verdade, chamando internamente parseInt , o que explicaria por que ele leva mais tempo do que um simples parseInt . No entanto, eles têm a vantagem de serem mais significativos, sem exigir que uma function definida externamente (ou seja, em algum outro lugar do arquivo ou do aplicativo) seja executada, com o construtor Number realmente minimizando a conversão visível de um inteiro em uma cadeia.

Bottom line, esses números foram gerados em 10M iterações. Em um único item, a velocidade é incalculavelmente pequena. Para a maioria, simplesmente executá-lo através do construtor Number pode ser o código mais legível, apesar de ser o mais lento.

 @{ int proID = 123; int nonProID = 456; }  

Não tanto uma resposta como um conto de advertência: isso também estava me incomodando – e achei que tinha uma solução antecipando um zero e usando a syntax @(...) . ou seja, seu código teria sido:

 var nonID = 0@(nonProID); var proID = 0@(proID); 

Obtendo saída como:

 var nonId = 0123; 

O que eu não percebi foi que é assim que o JavaScript (versão 3) representa os números octal / base-8 e, na verdade, está alterando o valor. Além disso, se você estiver usando o "use strict"; comando, em seguida, ele irá quebrar seu código inteiramente como números octais foram removidos.

Eu ainda estou procurando uma solução adequada para isso.

Funciona se você fizer algo assim:

 var proID = @proID + 0; 

Que produz código que é algo como:

 var proID = 4 + 0; 

Um pouco estranho, com certeza, mas não há mais erros de syntax falsos, pelo menos. Infelizmente, os erros ainda são relatados no VS2013, portanto, isso não foi abordado corretamente (ainda).

Eu estive olhando para esta abordagem:

 function getServerObject(serverObject) { if (typeof serverObject === "undefined") { return null; } return serverObject; } var itCameFromDotNet = getServerObject(@dotNetObject); 

Para mim, isso parece torná-lo mais seguro no lado do JS … no pior dos casos, você acaba com uma variável nula.

Uma das maneiras fáceis é:

   

E, em seguida, obtenha o valor em javascript:

 var SaleDate = document.getElementById('SaleDateValue').value; var Item = document.getElementById('VoidItem').value; 

Eu uso uma function muito simples para resolver erros de syntax no corpo de códigos JavaScript que misturados com códigos Razor 😉

 function n(num){return num;} var nonID = n(@nonProID); var proID= n(@proID);